Connectivity is an essential part of the overall IoT system. In the rapidM2M ecosystem, connectivity involves a variety of mechanisms. In doing so, emphasis was placed on the fact that many challenges and problems that arise during the life cycle of an IoT or M2M product are already are solved by default. At the same time, a high degree of flexibility and adaptability are essential in order to adapt the technology and the rapidM2M ecosystem precisely to the individual requirements of each project.
The SIM chip, for example, is already integrated on the module and permanently soldered. Comprehensive SIM management in the background ensures that you don’t have to take out individual contracts for each device and keep an eye on the data volume. It also ensures that you don’t burn money with basic charges while devices are in stock and waiting to be put into operation.
But the topic alone offers potential for its own article. Here we want to focus on 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 and is exchanged between the device and the server. For this purpose, rapidM2M provides a predefined data structure, which gives you the necessary freedom to customise the transferred data to your application. This concept ensures a certain application-independent basic functionality.
In the container “devices state” stores the current status of the device as well as information on the last transmission and the hardware and firmware version.
Another container takes care of time management. This synchronises the time on the device and the server. Functioning time management is essential so that you can synchronise devices and your Digital Twin. But also to put the measured values in the correct order, a current timestamp is relevant.
Positioning 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, if a GPS receiver on the device to transmit the position (longitude and latitude) via this container. On the server, the device is displayed on a map using this position.
Freely usable data blocks
The 10 Config and Histdata blocks are freely definable. They are designed for different areas of application. It is therefore important to look at their specific properties.
The Config Container is used to exchange application-specific parameters between the server and the device. The values are not saved historically and therefore only the current value is available. Based on the timestamp, the config blocks are synchronised with each transmission and synchronised accordingly.
For example, if you are developing a warehouse management or inventory management, such as TeDaLoS, you can store the weight of your monitoring object (e.g. a screw or a drinks bottle) in the config container. Now you can easily draw conclusions about how many pieces are still available and realise automatic reordering.
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 temporarily stored on the device and transmitted to the server at the transmission interval. The time series are permanently saved and can be displayed in a progression chart, for example.
To stay with the example of stock monitoring, you would store the measured weight in the Histdata blocks, including the timestamp supplied as standard;
The File Transfer is a container for transferring large amounts of data. Which data this is and what happens to it must be customised for the specific application. For example, the container can be used to transfer images from a measuring point to the server, e.g. in the projects D-Eye® or Fieldeye.
File transfer is particularly suitable for Firmware or operating system update of connected devices or machines. This container is first used to ensure that the large file is completely transferred from the server to the device. Even with a poor connection, which is repeatedly interrupted, this is possible in a resource-saving manner. The file is transferred bit by bit and does not start completely from the beginning with each attempt. The update is only executed once the file is complete on the device or machine.
Predefined structure with necessary degrees of freedom
The insight into the data structure clearly shows that with rapidM2M some tasks are already solved for you out of the box. You can easily use time management or the determination of the device position.
Nevertheless, with the Config and Histdata blocks you have enough freedom to create your individual application without compromise. With File Transfer, you can exchange even large amounts of data between devices and servers.
It is clear that it is essential to think carefully in advance about what data you need, when, where and in what resolution. This is the only way to realise an efficient IoT application at the end of the day.
In the course of the Discovery Workshops Microtronics helps you define these blocks to best support your business models behind the desire for data.
