To detect and immediately react to incidents is a classic use case for Industrial Internet of Things (IIoT) applications. Of course, you don’t want to mess with production machinery in a factory to develop your software application. Using a model and simulator to stage, record, and replay incidents provides flexibility to prototype, iterate, and test your software without touching actual factory machines.
Simulating incidents requires a baseline data stream that represents normal operations of a machine. For example, a constant flow of product data. A singular event then interrupts such a constant stream. This might be something like sensor data of an incident.
For the abstract IIoT factory model, we want to stage several scenarios with various product data and incident data. We want to flexibly develop software or data pipelines that react to sensor data that indicates incidents. And we want to see the results of such reactions to sensor data in the real world equipment of our model.
In our previous blog post, we explained how to create a camera-based product-reader model reading QR code strips. We also showed how to flexibly create such QR codes from a JSON file with product data.
In this blog post, we share how to create a physical conveyor-belt model and stage an incident that causes an emergency shutdown of the model.
To prepare incident data, use the same method as for producing the QR code based product data stream you find in our previous post. Instead of strips with multiple product variants, we produce a strip with incident data compatible with our open source IIoT Server. Our file in `./qr_data/` is called “incidents.json” and looks like this:
Next, run the script `ruby ./make_qr_strip.rb incidents`, open the generated HTML page “./qr_strips/incidents.html” in a web browser, and print it. Cut out the QR codes and glue them to the back of a coaster. We recommend writing the type of incident on each coaster to recognize them later.
Put the incident-data coasters on your product data strip and watch the product-reader model read the incident data and print it to your screen.
We want to send the warmest thank you to the etventure tech guild team for their great support on building the model’s hardware and sensors! This wouldn’t be possible without your help.
Our factory model has a total of four 3D-printed rollers, each of which consists of two halves that screw together. One of these rollers propels the conveyor belt and has a special design. Instead of an even surface, this roller has a lot of grip and a gear attached, so the motor can propel it.
Thanks to our friends at the etventure tech guild team, we are using a wooden laser cut frame for the model. If you have carpentry skills, you could build a similar frame, of course.
Our IIoT-factory model frame has two side panels with a couple of notches for the 3D printed rollers, the stabilizing bridges and the motor. The stabilizing bridges between the side panels are in a separate model file. Their current versions are all available for download here.
Select a corner of your frame to place your stepper motor and mount it. Do not tighten the screws too much, since adjustments may be necessary after mounting the rollers. On the inner side of the panel, attach the small 3D printed cogwheel to the stepper motor.
Pick the 3D printed roller with the attached gear, turn it so that the gear is in the corner of the motor and put it in the notch. Adjust the position of the motor so that the roller rests easy, but the motor’s small cogwheel still tightly fits into the roller’s gear.
The stepper motor we use on our IIoT factory model is set up with the x-axis slot of an Arduino motor controller. The motor can only be started by supplying power via USB and stopped by pulling the USB plug. We added a startup sequence that slowly accelerates the motor up to a certain speed to optimize grip on the conveyor belt.
The ideal material for your conveyor belt is thin, light, flexible, and durable. Depending on the total size of your model, the length of your raw material could be important, too.
For our IIoT factory, we used a 2m-long travel yoga mat. They are made of rubber—an ideal material— and are much thinner and lighter than regular yoga mats. We just cut it to the right length and glued the ends together to form a belt.
Let’s put together the components. Put up the wooden side panels stabilized with bridges. Put the conveyor belt correctly around the rollers and fit them into the notches. Make sure the one gear attached to a roller is in the corner where the motor is. Adjust the motor’s position so it’s cogwheel fits with the roller gear. Wire up the Arduino motor controller with the motor plug the motor’s USB power supply into a smart plug configured to work with IIoT Server. Make sure initially your smart plug is switched off.
Put your product-reader model on top of your IIoT-factory model and make sure the distance and angle of its camera enable it to read the QR code product data strips on the conveyor belt.
Once everything is assembled, put your product-data strip on the conveyor belt and keep an incident coaster in your hand to throw in at will. Start the conveyor belt by switching on the smart plug by sending an HTTP request to your local IIoT Server API.
Throw in your incident coaster and the event data should be printed to screen. As we do this we record a trace file that we can replay in the simulator later. It looks like this:
You could either build by hand a software script with decision logic sending the HTTP request to switch off your smart plug if an incident is recorded on your own Kafka server. It would need to work well with the simulator we suggested building in our initial post.
Or you could create a Xapix Community Edition account and follow the final steps of this article.
Follow the instructions on how to set up a Xapix pipeline we provided in our initial blog post of the series
For the IIoT-factory model shutdown pipeline, subscribe to the demo Kafka server’s topic “demo_iot_factory-incident”. Use an incident event as a data sample for the event unit:
On the pipeline dashboard create a decision unit with a branch called “fire” and a formula that checks if the sensor event is a fire: `event.body.value = "FIRE_ON_BELT"`
Connect two of your external executor units to the fire decision branch. Configure one of them to, for example, play an “alarm.mp3” you need to add to `./tmp/factory/media/` folder in your IIoT Server instance. Configure the other one for device “conveyor_belt_plug” and command “plug_off” to switch off your smart plug and therefore stop the conveyor belt.
Publish your project and test your setup by starting your factory via cURL, just as you did earlier in this post. Feed your factory IIoT model some product data strips and eventually throw in your fire incident coaster. The Xapix Community Edition pipeline will react to the emergency event and shut down your factory.
Use the Trace File Player software to replay the factory trace files. We added our recorded trace file with the incident to the simulator inventory. Send a job description to the simulator API per HTTP POST https://mobility.xapix.io/trace-player/trace_player_jobs:
We are working on follow-ups to this blog series and will post updates in our Discord community to inspire you with new ideas about how to use the Xapix IIoT Server once you have set it up. We would love to hear your ideas and collaborate!
Contact us on our Discord community channel if you would like to discuss this tutorial or if you have questions or feedback about the Xapix Community Edition. Or really anything else as well. We look forward to hearing from you!
Oliver is a senior software developer and an API and data transformation enthusiast. He’s a co-founder of Xapix, writer and conference speaker on all things API. Most recently, he’s bringing his perspective and experience to the world of Industrial IoT.