The connectivity is an essential part of the an overall IoT system. In the rapidM2M ecosystem, connectivity contains multiple mechanisms. It has been emphasized that many challenges and problems, that occur during the life cycle of an IoT or M2M product are already solved by default. At the same time, a high degree of flexibility and adaptability is indispensable in order to adapt the technology and the rapid2M ecosystem exactly to the individual requirements of the respective project.
The SIM chip, for example, is already integrated on the module and soldered. Comprehensive SIM management in the background ensures, that you do not have to conclude contracts for each individual device and keep an eye on the data volume. It also ensures that you don’t burn money with a basic fee when devices are in stock and waiting to be commissioned.
This subject alone offers potential for an own article. In this article we want to focus on the synchronisation of data and take a look at the functionalities rapidM2M offers in this context.
Predefined data structure
The synchronisation mechanism ensures that your data always arrives an d is exchanged between the device and the server. rapidM2M provides a pre-defined data structure that gives you the freedom you need to adapt the transmitted data to your individual application.
In addition to the current status of the device, information about the last transmission as well as the hardware and firmware version is stored in the device status container.
Another container takes care of the time management. This container synchronises the time on the device and the server. To be able to synchronise devices and their digital twin, a functioning time management is indispensable. However, a current time stamp is also relevant I order to bring the measured values into the correct sequencechronical order.
Position determination is required in many IoT projects. Therefore, the last GSM cell information is transmitted by default. The position is then calculated on the server. Alternatively, the position (longitude and latitude) of an existing GPS receiver can be transmitted via this container. The device is displayed on a map on the server using this position.
Freely usable data blocks
The 10 config und and histdata blocks are freely definable. They are designed for different applications. Therefore, it is important to consider their specific properties.
The config container is used to exchange application-specific parameters between server and device. The values are not stored historically and therefore only the current value is always available. Based on the timestamp, the config blocks are synchronised with each transmission.
If, for example, you develop a warehouse management or an inventory management, as TeDaLoS has done, you can store the weight of your monitoring object (e.g. a screw or a beverage bottle) in the config container. Now you can easily draw conclusions about how many pieces are still available and realize an automatic re-order.
The 10 histdata blocks, on the other hand, contain a time stamp in addition to the freely defined measured values and are created in the recording interval. They are stored temporarily on the device and are transferred to the server at the transmission interval. The time series are permanently stored there and can be displayed in a history diagramline chart, for example.
The File file Transfer transfer container is for transferring larger amounts of data. Which data this is and what happens with it must be adapted to for the specific application. For example, the container can be used to transfer images from the measuring point to the server as has been done in projects such as D-Eye® or Fieldeye.
The file transfer is very popular for firmware or operating system updates of connected devices or machines is very popular. First, this container ensures that the large file is transferred completely from the server to the device. This is possible in a resource-saving way even with during a bad connection, which are is interrupted again and again. In a resource-saving way, the device already knows what has been transferred and what has arrived. The file is transferred in pieces and does not start from the beginning every time it is attempted. Only if the file is complete on the device or the machine, the update is executed.
Predefined structure with necessary degrees of freedom
The insight into the data structure clearly shows that with rapidM2M some tasks have already been solved for you by default. You can easily use time management or the determination of the device position.
Nevertheless, the config and histdata blocks give you enough freedom to map your individual application without compromise. With File file Transfertransfer, even large amounts of data can be exchanged between devices and server.
It becomes clear that it is essential to consider exactly in advance which data you need, when, where and in which resolution. This is the only way to realize an efficient IoT application at the end of the day.
During the Discovery workshop, Microtronics will help you define these blocks to best support your business processes behind the desire for data.
Latest posts by Sabrina (see all)
- Connectivity by Design – The Synchronisation of Data - 04/23/2019
- Where digitisation creates jobs - 03/07/2019
- Transformation as the cornerstone of sustained success - 10/25/2018