... | ... | @@ -32,8 +32,11 @@ In the following different IIoT Kits will be evaluated regarding their suitabili |
|
|
| [CUBIDO IIoT Jump Start Kit](https://www.cubido.at/services/iot/iiot/jump-start-kit) | (1) ifm IO-Link sensors: <br/>RGB LED pilot light, photoelectric barrier, RFID reader, temperature and humidity sensor <br/>---<br/>(2) ifm IO-Link sensors: <br/>magnetic pulse sensor counter, temperature and humidity sensor <br/>---<br/>(3) ifm IO-Link sensors: <br/>vibration sensor, temperature and humidity sensor | IO-Link Master?, CloudRAIL.Box | IO-Link <br/>Microsoft IoT Central <br/>OPC UA <br/>CloudRAIL.Box should support MQTT | Azure subscription necessary <br/>includes Kick-Off workshop <br/>data of existing sensors can be included using OPC UA <br/>individual kit possible |
|
|
|
| [Amazon Monitron](https://aws.amazon.com/de/monitron/) | vibration and temperature sensors | Monitron Gateway | Bluetooth Low Energy <br/>Ethernet or Wi-Fi Gateway <br/>AWS Cloud | Kit was already purchased <br/>setup with mobile App <br/>reverse engineering might be necessary |
|
|
|
|
|
|
All IIoT kits mentioned in the table above are designed for use in industrial environments. While the test field only contains simple, unprotected sensors now, one could use one of these kits to demonstrate more industry-oriented use cases. Supported technologies like OPC UA and IO-link furthermore allow the usage of other sensors. In the industry this could be sensors already being used for production. Additionally, own software is provided or well-known cloud platforms are supported. An easy setup as well as already given functionalities like predictive maintenance are promised. But a huge disadvantage of the included software solutions is the need for subscriptions. The CUBIDO kit for example might need one for Azure. Only PEPPERL+FUCHS explicitly states that stand-alone applications can be realized using for example the REST-API.
|
|
|
|
|
|
- Full IIoT solution without PLC
|
|
|
An alternative to the mentioned IIoT kits would be to purchase the hub / gateway and sensors separately. One could just use hardware providing an interface which allows to connect it to the existing test field. In this case, the software needs to be implemented from scratch. But solutions already including support for major cloud platforms are possible as well. For example, the [CloudRAIL.Box](https://cloudrail.com/cloudrail-solution/) also included in the CUBIDO kit together is available separately and could be used as edge gateway. But the CloudRAIL.OS is also available as Docker container which enables the use of CloudRail on any edge hardware. A public API allows to access CloudRail Device Management Cloud. Unfortunately, a CloudRail subscription might be needed.
|
|
|
|
|
|
In my oppinion, it would be nice to actually include a machine into the testsystem. In the first step, one could add separate sensors to it which would not impact the functionality. Equipping an already existing / running machine with additional sensors is common in retrofitting. The sensors could be used for condition monitoring or predictive maintenance. Optionally, one could try to realize a full-IIoT solution.
|
|
|
|
|
|
### Application scenarios
|
|
|
|
... | ... | @@ -65,5 +68,5 @@ Monitron is comparable to the third CUBIDO kit. Combined with the software based |
|
|
|
|
|
Because of the delivery times and my lacking experience with BaSyx I decided to first add a RFID reader connected to a Raspberry PI to the demonstration. This helped me to understand how BaSyx works and what might be possible using the SDK. Nonetheless, it is hard to say what will work with the demonstration due to the incomplete documentation.
|
|
|
|
|
|
As the RFID reader is stationary, tags have to be placed on it. Currently, the text and id of a chip are displayed when it is read. One could use this information to for example differ between different user groups. Depending on the group different data could be displayed. For example one could show just the messured values for a standard user and more detailed information for another group. Debug messages could be displayed if a developer chip is read. Because unlike the IDs of the RFID tags the text can be changed, a database for storing tags and their corresponding rights might be necessary.
|
|
|
As the RFID reader is stationary, tags have to be placed on it. Currently, the text and id of a chip are displayed when it is read. One could use this information to for example differ between user groups. Depending on the group different data could be displayed. For example one could show just the messured values for a standard user and more detailed information for another group. Debug messages could be displayed if a developer chip is read. Because unlike the IDs of the RFID tags the text can be changed, a database for storing tags and their corresponding rights might be necessary.
|
|
|
Alternatively, RFID tags could be used to invoke different operations or to override functionality for a set amount of time. |