Imagine a well established manufacturer of Totis. A Toti consists of many Toti parts which are assembled automatically by very sophisticated robots. When one of the Toti parts shows a special defect these robots become seriously confused and long production delays are the result. So the company decides to install a vision system which inspects this Toti part and rejects it if it shows the critical defect. The Toti manufacturer approaches your company with this problem. Because there are many other producers of Totis who most probably have the same problem you sense a good opportunity to sell a lot of vision systems. You ensure the manufacturer that you will develop a solution for his problem if he provides you with all the necessary information about the production of Totis and images of the assembly situation in question.
You send some experienced developers to the production plant and they return with a batch of images of Toti parts with and without defects. Full of curiosity you start throwing algorithms at the images to find out whether your dream of selling thousands of Toti inspection machines will come to a sudden stop after a couple of experiments. Luckily, after a few days work you invent an algorithm which perfectly solves the problem. The images must undergo some pre-processing before they can passed to your algorithm but the code for these steps can easily found in well-known image processing libraries. Relieved that you are ready to earn a fortune in the Toti business after just a couple of days work you start the construction of the inspection device.
Since the hardware components such as camera and illumination devices have already been selected during the acquisition of the test images the main focus is on the software which controls the camera, analyzes the images and communicates the inspection result. At this stage you remember that some time ago you read this article about a software package called stromx which promised to provide an efficient infrastructure for such a solution. After downloading stromx you soon realize that the framework provides all the image processing operations for the pre-processing steps which are necessary before your algorithm can be executed. Obviously, the state-of-the-art Toti inspection algorithm you engineered only a couple of days ago is not a part of stromx (in fact you hope that nobody will ever implement one and open source the basis of your future fortune). However, you can still import your algorithm into the stromx framework by implementing a stromx operator which wraps your algorithm. The result is a shared object which can be imported into the stromx-studio. You use the same technique to implement a stromx operator which drives the very special and sophisticated camera which will be part of the inspection device.
Now you are ready to start stromx-web in your web browser. You drag instances of the camera operator, the Toti inspection operator and all necessary pre-processing operators to the main area. After connecting their inputs and outputs you press the play button. Your first stromx stream starts to work! While the stream processes all images it obtains from the camera in an endless loop the parameters of its operators can be changed on the fly. In addition you select observers at various locations of the stream to display the flow at these points. In particular, the result of the whole processing pipeline can be visualized. After playing around a while you think that it might be good switch the sequence of the pre-processing steps. You save a backup copy of your current project and apply the changes. After tweaking some more parameters the results are indeed better than before.
Until now you did all implementations and experiments on your local PC. Satisfied with the results you choose to test your stromx stream on the final Toti inspection machine for the first time. The machine is equipped with an embedded PC which runs a special Linux version. Because the source code of stromx (and of course of your custom operators) is available, it turns out to be easy to compile and install it on the target system. Next you copy the project file to the embedded system and run it there. Because this can be done using the web browser on your local PC you do not have to leave your desk to deploy several versions of the stream on the target machine.
However, you are soon disappointed. While the inspection results seem to be okay the processing takes far too much time. Considering the possibilities of optimizing the wonderful Toti inspection algorithm it comes to your mind that although the CPU of the target system is not very powerful it does have a second core. Obviously, your implementation uses only one core. So one possibility to almost double the throughput of the inspection device is to start a second inspection on the second core while the first inspection is still active on the first one. At first this seems to require the implementation quite some synchronization and threading code but it turns out that stromx provides out-of-the-box support for such demands. You drag and drop a second processing pipeline in your stream and a assign a new thread to it. The two pipelines are fed by a fork operator and end at a join operator. Pushing the play button again immediately verfies the speed-up.
During a meeting in which you present the current result to the client new requirements turn up. First, the client wants you to turn on a right light on the machine whenever your algorithm detects a faulty Toti. Moreover, the result of the inspection should be written to an SQL database in such a case. To fullfill these demands you implement two more operators. One interfaces the PLC of your machine and switches the right depending on the value of its single input. The second one forwards the data at its input to an SQL server. Since the details of the SQL connections can be specified as parameters of the operator you can immediately integrate the operator in your stromx stream and test the results with a dummy server. A few tests in stromx-web show that both, the PLC operator and the SQL operator, can be integrated into the existing stream as expected. Being aware of the fact that these operators can be reused in any other inspection product you happily integrate them into your company's custom operator library.
In terms of functionality everything seems to be fine but you still have to run stromx-studio on the target system which then executes the inspection stream. This procedure does not meet the expectations of your marketing team which wants one slick, integrated GUI application reflecting your corporate identity. This is the point at which stromx starts to shine brightly. Instead of opening the stromx stream file in stromx-studio you can read it using the stromx API. Executing the stream then requires a simple stream->start(). The stream is automatically executed in a separate thread and stromx safely forwards all calls from the GUI thread to the execution thread. In other words, your GUI team can change the parameters of the operators while the inspection is running without caring about any concurrency issues. Moreover, because the operator interface is generic the GUI programmers are able to access parameters, inputs and outputs in a standard way regardless of the domain-specific details of the operator. Finally, since the final product depends only on the Apache 2.0 licensed library part of stromx your legal department does not see any danger for your intellectual property.
Under these circumstances the complete development is finished in record time and after passing all tests the inspection device is ready to ship. Because of its superior performance your customers are eager to equip whole factories with it and pay high prices. By the end of the year you receive an award for your achievements for the Toti industry.