The IoT tower of Babel. Part 1

09 February, 2018

The IoT tower of Babel

How to teach hardware and software speak the same language?

Internet connected things generate a variety of information: discrete states or continuous values of sensors, counters of physical values, textual information, settings and modes of operation, images, video and sound.  We will call such information as Parameters. Devices exchange parameters with a server and with each other. Parameters are displayed on a device indicator, in a user and service applications. In fact, the whole IoT paradigm is to collect, to process and to display some parameters.

A huge problem of IoT concept development is the loss of understanding on different segments of interactions: firmware with firmware, software with software and especially firmware with software.  The problem almost never appears itself while there are less than 10 parameters in the system and all system elements are developed by the same company. The problem appears in explicit form when there are several dozens of parameters from IoT system elements, especially when such elements produced by different companies. And the task of integration becomes intractable, when hundreds and thousands of parameters are to be integrated.

Where hundreds or thousands of parameters are taken from?

A) What about a challenge of complex objects monitoring. For example, a vehicle or some process unit, equipped with one or more digital buses, which provide joint work of nodes.

B) Or an object that equipped with a network of smart sensors, smart home or smart city, for example.

C) And don’t forget about smart sensor service parameters: serial number, network connection settings, calibration values, factory and installation configuration values, device performance statistics, etc.

 Popular IoT platforms such as Azure,  AWS, Watson and etc offer only the transport layer of the data transfer protocol, and an inside content is given to user. In analogy with the mail: you are guaranteed that a letter will reach you, but you may find a foreign language inside. Thus, a task of parameters interpretation goes into hands of interface programmers, who are far from hardware (things) or firmware programmers, who are alien to server software tools.

Symptoms of IoT misunderstanding problem

Typical symptoms of misunderstanding problem

1. Hardware & Software development time grows due to a large amount of work on testing and debugging.

2. There is a need in software or hardware converters which slows down your system, especially a preparation of analytical reports.

3. An accuracy of measurement parameters reduces due to converting to other data types.

4. Slow performance of server software.

5. The complexity of new devices integration, particularly from a third-party

6. Limited functionality. The function can be realized potentially, but the development complexity of analytical software absorbs possible benefits.

7. Documentation and technical support issues. The same parameter has different names in the various documents or, even worse, different parameters have similar names and that leads to confusion.

 

It`s high time to standardize IoT parameters. Hardware & software must learn understand each other.

 

Standardization implies

1. A unique number (Parameter ID)

2. Abbreviated and full name

3. Units of measurement

4. Format: type, offset, increment, length

5. A description of the parameter and the rules of usage

 

For over 15 years Technoton develops and manufactures Internet connected devices, we are well aware of the parameters standardization need.  And we have developed our own corporate standard, which I will observe in the next article.

 

Aliaksandr Kaplunski,

Founder and system architect of Technoton Engineering