HRP20220589A1 - Method of operation of modular iot box with verification of connected modules and associated system with plurality of iot boxes - Google Patents

Abstract

The subject invention reveals the way the modular IoT box (100) functions with the verification of the connected modules (10.i), i = 1, 2, ..., N, which are located in the slots (20.j), j = 1, 2, ... , M of this subject box and a system that monitors the operation of a plurality of such boxes. The modules are connected by a bus (30) to the data processing unit (40) using the I2C communication protocol. The data processing unit communicates with the system server (500) via the connection unit (50) and with the manual verification device (200) via the verification module (60) connected to the same data processing unit (40) in service mode. Each IoT box works in one of three modes of operation selected from: normal mode when the state of each module (10.i) is written or read through the server (500) in initially set time periods defined by the module frequency list (LFM), verification mode of operation when determining the functionality and number of built-in modules (10.i), and the service mode that enables reconfiguration of the box in question (100.k) by an external operator. The related invention discloses the operating method of the modular IoT box (100) with the verification of the connected modules (10.i), i = 1, 2, ..., N, which are located in the slots (20.j), j = 1, 2, ..., M of the box and a system that monitors the operation of a plurality of such boxes. The modules are connected by a bus (30) to the data processing unit (40) using the I2C communication protocol. The data processing unit communicates with the system server (500) via the connection unit (50) and with the manual verification device (200) via the verification module (60) connected to the same data processing unit (40) in service mode. Each IoT box operates in one of three modes of operation chosen from: normal mode when the state of each module (10.i) is written or read through the server (500) in initially set time periods defined by the module frequency list (LFM ), verification mode of operation when determining the functionality and number of installed modules (10.i), and the service mode that enables the reconfiguration of the related box (100.k) by an external operator.

Description

The field of technology

The subject invention relates to a new and improved modular IoT (Internet of Things) box with verification and management of connected modules of various purposes in the box itself. Such modular IoT boxes are used in industrial processes of data acquisition from many IoT sensors, industrial automation where it is necessary to manage industrial processes from a separate place, in industries that use redundant safety sensor systems and controls, robotics, telecommunication services and all other processes that include multitude of measuring and control quantities of the system itself. Therefore, the field of technology seems to be defined as the field of transmission systems for measured values, control or similar signals. Additionally, in the subject invention, wireless communication is achieved with a multitude of mentioned IoT boxes that either manage processes or collect measured values from the built-in modules in the modular IoT box. With regard to the technical problem discussed below, this invention also belongs to the technical field of protecting computers, their components, programs or data from unauthorized activities by third parties.

Technical problem

The Internet of Things (IoT) refers to the equipment of physical objects (or groups of such objects) with sensors, data processing capabilities, software and other technologies that connect said objects and exchange data with other devices in other objects and systems via the Internet or other communication networks or communication channels. The Internet of Things is considered a catch-all term, although the devices themselves do not necessarily need to be connected to the Internet, they just need to be connected to a computer network or data exchange network with the ability to be individually addressed.

The IoT field has developed due to the convergence of multiple technologies, including ubiquitous computing, sensors, and especially machine learning systems. The traditional areas of incorporating IoT technology are process systems, wireless sensor networks, control systems, automation (including automation of homes and buildings), where everything - independently and collectively enables the application of the Internet of Things. In the consumer market, IoT technology is mostly synonymous with products related to the "smart home" concept, including devices such as lighting fixtures, thermostats, home security systems, control of video surveillance and other household appliances that support one or more so-called ecosystem, and can be controlled through devices connected to that ecosystem. Smartphones and smart speakers are most often used for such control. IoT is also used in healthcare systems.

But there are also a number of concerns about the risks in the growth of IoT technologies and products. This is particularly the case in the areas of privacy and security. Consequently, the IoT industry is turning to addressing these issues, including the development of international and local standards, guidelines, and regulatory frameworks to prevent intentional obstruction or inadvertent error in the operation of IoT systems.

Work from reference 1):

1) Tawalbeh, L., Muheidat, F., Tawalbeh, M., & Quwaider, M. (2020). IoT Privacy and Security: Challenges and Solutions. Applied Sciences, 10(12), 4102. doi:10.3390/app10124102

discusses the background of IoT systems and security measures and identifies various security and privacy issues of IoT technology. Additionally, the paper analyzes the approaches used to secure components of IoT-based environments and systems and discusses existing security solutions. This paper suggests privacy models that are necessary and appropriate for different layers of IoT applications, such as the need to encrypt information when exchanging data within different layers of IoT systems.

On the other hand, the subject invention is concentrated only on a part of the technical problems listed above that occur on system nodes, which are sensitive to unauthorized use. Such places represent modular IoT boxes that are used to concentrate sensor modules or control modules of IoT systems. IoT boxes are often located in inaccessible places, places that are not always monitored or placed in isolated places - and they are vital for the functioning of the system. However, such places are very problematic and expensive to ensure adequately to prevent, for example, arbitrary modification or addition / connection of additional IoT modules to the infrastructure, for example "fake" modules with addresses that emulate real IoT modules but have a different purpose. Namely, the IoT infrastructure is designed for easy addition of IoT modules, which is in contrast to the growing security requirements. For example, when using the I2C protocol for serial communication between IoT modules, it is enough to have only two wires for signal transmission, see for example https://i2c.info/ and a power supply in order to add a new module to the system. Such simplicity of adding modules also creates a great potential danger for compromising the functionality of the system itself and unintentional errors when adding or removing modules.

Moreover, it should be said that each sensor or module of an IoT system that is designed to use the above I2C communication protocol has its own hardware unique and immutable device address, see for example: https://i2cdevices.org/devices. This fact facilitates communication with IoT boxes, but complicates the control of changing modules without authorization, authorization and detection of connection of new IoT modules, self-diagnostics and detection of errors in the system, as well as management of a large number of nodes - modular IoT boxes in real time.

The basic technical problem that is solved by the subject invention is the administration of such IoT boxes in a safe way by a server that manages a multitude of boxes. This administration also includes adding sensors or modules that have the same addresses in such a way that the system server records them as different devices, on-demand system diagnostics or auto-diagnostics, and prevention of arbitrary module changes. Therefore, the security aspect of the entire IoT system from the user's point of view and the practically impossible addition of modules without authorization is presented in a new and inventive way by this subject patent application, with the condition that the standard I2C protocol and standardized I2C devices are still used, and if necessary, cryptographic data exchange methods between layers, eg between IoT boxes and system servers.

Prior art

The technical problem discussed in the previous chapter appeared immediately with the I2C standard. For example, reference 2) discusses a security system implemented at the hardware level, specially designed for the I2C protocol:

2) US patent US 6,510,522 B1 for the invention entitled: APPARATUS AND METHOD FOR PROVIDING ACCESS SECURITY TO A DEVICE COUPLED UPON A TWO-WIRE BIDIRECTIONAL BUS; copyright holder is Compaq Information Technologie [US]

In the references that follow, you can see the effort of the world's leading companies to adequately solve the mentioned technical problem at a relatively early stage of the creation and use of the I2C protocol from 5, 10 or more years ago:

3) US patent application US 2016/210480A1 for the invention entitled: ACCESS AND PROTECTION OF I2C INTERFACES; rights holder IBM [US],

4) US patent US 7,779,254 B1 for the invention entitled: MECHANISM TO ENHANCE AND ENFORCE MULTIPLE INDEPENDENT LEVELS OF SECURITY IN A MICROPROCESSOR MEMORY AND I/O BUS CONTROLLER; rights holder ROCKWELL COLLINS INC [US], and

5) US patent US 7,398,345 B2 for the invention entitled: INTER-INTEGRATED CIRCUIT BUS ROUTER FOR PROVIDING INCREASED SECURITY; copyright holder Hewlett-Packard Development Company [US].

All the technical solutions listed above refer to solving problems, most often at the level of hardware functioning. On the other hand, references 6), 7) and 8) refer to (modular) boxes designed to acquire data from a multitude of sensors, especially sensors used in Industry 4.0:

6) US patent US 11,067,976 B2 for the invention entitled: DATA COLLECTION SYSTEMS HAVING A SELF-SUFFICIENT DATA ACQUISITION BOX; rights holder Strong Force IoT Portfolio 2016 LLC [US],

7) International patent applications published as WO 2005/101281 A1 for the invention entitled: FIELD REPLACEABLE SENSOR MODULE AND METHODS OF USE THEREOF; rights holder Tyco Flow Control Inc. [US], te

8) Review paper, Dave Astels: MULTI-SENSOR IoT ENVIRONMENTAL SENSOR BOX WITH CIRCUITPYTHON, which is available at the link: https://learn.adafruit.com/remote-iot-environmental-sensor

Reference 8) describes in detail the performance of a device, say an IoT sensor box, which is equipped with GPS, temperature, humidity, pressure and air quality sensors. According to the solution described in this way, all sensors update their values according to the computer cloud, and in such a way that the values are read and sent with time and location characteristics, via the Wi-Fi network, in order to enable both location tracking and sensor tracking in time. However, it is still a hobbyist device where security issues are of secondary importance.

The subject technical solution of this invention solves security problems by using existing standards and authorization procedures that are more oriented towards a computer-implemented invention where a part of the verification computer code, which is located in each of the IoT boxes (or technically speaking routers for the modules) in the processing unit data - permanently performs the technical function described earlier in the section as a technical problem.

The essence of invention

The subject invention is oriented to the protection of the work procedure of a modular IoT box within a system with P modular boxes, k = 1, 2, ... P, where each of the aforementioned IoT boxes consists of:

A. an arbitrary number M of module slots, dimensionally and electrically designed to accept an arbitrary number N of modules, where N ≤ M, and where all modules are designed to communicate with the I2C communication protocol in such a way that they have their own unique I2C address,

B. where the modules are arbitrarily chosen from a set of I2C devices without restrictions, and in particular from a group of different sensors, analog-to-digital converters (ADP) and digital-to-analog converters (DAP), radio modules as well as modules for display and data entry,

C. buses, designed to connect IoT modules operating in slave mode by appropriate wiring to a data processing unit configured to operate in master mode,

D. optional, one or more multiplexers built into the bus that allow the use of two or more modules with the same purpose and the same built-in I2C address in such a way that the data processing unit, for the sake of said mutiplexer, sees them internally as a set of completely different modules with different I2C addresses within the same I2C connection scheme, a

E. where the data processing unit is additionally connected to the connection unit and at least one verification module that is implemented either independently or as one of the modules of the IoT box, where the purpose of the data processing unit is to process the signals received from the mentioned modules or the managed behavior of an individual module and verification module, and establishment of communication through the unit with connection to the external server of the system.

The aforementioned IoT box prevents arbitrary modification or addition of modules in the slots it monitors, and performs self-diagnostics. This is solved in such a way that the mentioned box executes one of the three possible modes of operation which are chosen from:

- normal mode of operation when the modules communicate with the server via the mentioned box in the initially set time periods defined by the frequency list of the built-in modules (LFM),

- verification mode of operation when determining the functionality and number of installed modules, and

- service mode that enables the reconfiguration of the box in question and the modification/replacement of the module by the operator.

In normal operation mode, the data processing unit is configured as a master that communicates with the i-th module configured as a slave with a frequency that is previously defined for the given module and is locally stored in the list of module frequencies (LFM), and in the communication phase:

- or the read value from a specified module is forwarded via the connection unit via one of the compatible gateways to the server,

- or the previously received value for the specified i-th module from the server, and stored in the memory of the data processing unit, is written into the module register of that module in order to perform the function of the mentioned module.

In the verification mode, the data processing unit scans all available I2C addresses of the connected modules, saves the read list of available addresses locally as L1 list and compares the newly read L1 list with the previously saved L0 list. If:

(i) L1<>L0 repeats state verification up to R times and generates additional lists L2, L3, … LR, and in case all lists from the set {L2, L3, …, LR} are different from L0, the data processing unit reports , through the connection unit, the server about the read error on the box k and the need for physical service or control of the circuits of the box k; and if at least 50% of list values selected from {L2, L3, …, LR} are identical to list L0, then the data processing unit reports, through the connection unit, the server about the transient difficulty of the system and continues writing or writing data to/from module in normal operation mode; or

(ii) L1 = L0 the data processing unit reports, through the connection unit, to the server about the normal functioning of the box k and continues to write or write data to/from the module in normal mode, and

where the verification mode is switched on either periodically or via a verification module activated from the immediate vicinity of the box itself k.

Service mode is activated by connecting a manual verification device to the verification module of the selected box, where the data processing unit contains a list of digitally signed identifiers that must match the verification device used to connect to prevent unauthorized connection. At the same time, the verification device also informs the server, and additionally the IoT box independently informs the server that the service treatment has started on the k-th box. After that, the server, through the verification device, reserves a time period T during which the aforementioned box k cannot independently perform the verification mode, and a predefined modified list of modules L0 with corresponding frequencies of the module LFM, which the service technician made on the box in question, through his verification device it is written directly into the memory of the data processing unit, after which the variable T is set to the value T=0 and at least one verification mode is performed. If the verification mode is transitory, this information is transferred via the verification module and displayed on the servicer's verification device, after which the box operation mode switches to normal, and the verification device independently informs the server that the box is fully operational.

In one of the aspects according to the invention, the verification module selected from the group consisting of NFC or Bluetooth® Low Energy circuit that enables two-way communication between the verification module and the verification device. The verification device is preferably a mobile device equipped with a compatible circuit for communicating with the verification element or IoT box module. In another aspect according to the invention, the connection unit is selected from WI-FI, LoRaWAN and Bluetooth Low Energy radio modules, preferably LoRaWAN modules, and is implemented either as an independent module connected to the data processing unit or as one of the modules of the mentioned IoT box .

The subject invention also discloses a system for monitoring the operation of a number of modular IoT boxes with P modular boxes previously described, which additionally consists of a server, a monitoring console of the system itself, a verification device and a series of Q gateways. The essential characteristic of the system is that:

- each of the mentioned verification devices communicates, in a unit of time, only with one IoT box k and system server,

- that the series of gateways is the same or mutually different and chosen from the group consisting of: Wi-Fi, LoRaWAN or Bluetooth Low Energy gateways, and where the said gateways are compatible with the built-in IoT boxes to which they are connected and enable a reliable connection of the IoT boxes with the server via internet,

- that the system records in time the state of each of the modules installed in a box and monitors the state of all configuration changes of the mentioned modules in each IoT box, and maintains service lists that are reported to the operator via the monitoring console, and

- the system itself allows third parties to communicate with the server for further analysis and management of data that is loaded into or read from the modules located in the IoT boxes in order to monitor the processes related to the mentioned IoT boxes.

In one aspect of the invention, all verification devices in the system are equipped with a location service, which, when connected to a verification module of a certain IoT box, forwards, as a control element, the location where the IoT box was read to the server, and in the absence of a GPS signal, triangulation of mobile signals is used operator and thus determines the approximate location of the IoT box in service mode.

The subject invention also reveals the use of modular IoT boxes in industrial processes of data acquisition from many IoT sensors, industrial automation where it is necessary to manage industrial processes from a separate location, in industries that use redundant security systems of sensors and control, robotics, telecommunications services and all other processes which include IoT modules that function via the I2C protocol.

Brief description of the drawing

Drawing 1 is a schematic representation of a modular IoT box according to the subject invention.

Drawing 2 represents the way to activate the service mode from the immediate vicinity of the modular IoT box.

Drawing 3 is a schematic view of the system of connecting a number of modular IoT boxes monitored by a single server.

Detailed description of the invention

As has been mentioned several times, the subject invention relates to a new and improved modular IoT (Internet of Things) box with verification and management of connected modules of various purposes. Such modular IoT boxes are used in industrial processes of data acquisition from many IoT sensors, industrial automation where it is necessary to manage industrial processes from a separate place, in industries that use redundant safety sensor systems and controls, robotics, telecommunications services and all other processes where there is a need to replace embedded IoT modules.

The IoT box (100) itself, disclosed according to the subject invention, is shown in drawing 1. The IoT box (100) consists of a housing for housing an arbitrary N number of IoT modules (10.i), i = 1, 2, ..., N, within the M slots provided for the module (20.j), j = 1, 2, ..., M, with the condition that N ≤ M is satisfied. In the present invention, all modules (10.i) are designed for communication using the I2C communication protocol in such a way that each module has its unique I2C address (11.i).

For the purposes of this text, the module (10.i) "placed" in the slot (20.j) has one of three equivalent meanings:

- that the module (10.i) is physically located in that tu (20.j), or

- that the module (10.i) is connected to that slot by electronics, for example with its analog-to-digital converter, while, for example, the sensor part - for example, an NTC resistor for measuring temperature - is outside the IoT (box) at the place where the temperature is measured , or

- that the module (10.i) is moved outside the box, say the accelerometer of the robotic arm, but is physically and electrically connected to the slot (20.j) of the IoT box.

A list of such IoT modules is available on pages dealing with I2C communication issues, for example: https://i2cdevices.org/devices. The communication standard is described in the document that can be found at the link: https://www.nxp.com/docs/en/user-guide/UM10204.pdf.

Over the years, the I2C-bus has become a de facto world standard that is now implemented in over 1,000 different modules and licensed to more than 50 companies engaged in the production of IoT modules. Thus, among the listed modules we find different sensors selected from the group of sensors: temperature, humidity, pressure, gases; series of analog-to-digital (ADC) and digital-to-analog converters (DAC), accelerometers, magnetometers, IC (infrared) distance sensors, EPROM memories, and all kinds of other Industry 4.0 modules used in measurement and control electronics. In particular, the sets of radio modules for various purposes, selected from Bluetooth Low Energy (BLE), NFC, Wi-Fi, and even LoRaWAN modules, stand out here. There is practically no sensor, I/O unit or converter that cannot be found adapted for I2C communication. It is known that the advantages of the I2C standard are in the simple communication that literally takes place serially "by two wires" in such a way that a master device calls a slave sensor, ADC or similar module (10.i) via an address (11.i) that is factory set built into said module (10.i). In this way, values can be written into the module (10.i) and, of course, values can be read from a module (10.i) - which enables remote control.

Of course, this simplicity of the standard also has its problems in application when one wants to connect several modules (10.i) to the same I2C bus (30) - for the same purpose, say for redundancy and increasing the accuracy of measurements. The I2C standard is not adapted to such a solution. The way out of this situation is the existence / use of one or more multiplexers (MUX) (31) built into the bus. Using such multiplexers (31) allows two or more modules with the same purpose and the same built-in I2C address to be mapped as a set of completely different modules (10.i) with different I2C address (11.i) within the same I2C connection scheme. For such purposes, for example, the Adafruit TCA9548A 1-to-8 I2C Multiplexer can be used, see: https://learn.adafruit.com/adafruit-tca9548a-1-to-8-i2c-multiplexer-breakout

For the normal functioning of this IoT box, in addition to the mentioned modules (10.i), at least one data processing unit (40) equipped with internal memory, implemented in the form of a micro-controller, eg ATSAMD51 https://www.adafruit.com/ product/3857 or a more sophisticated system, say https://www.arduino.cc/. In addition to the above, a power supply (70), a connection unit or module (50) and a verification module (60) should be added.

Dimensioning the capacity of the power supply (70) depends on the frequency of use of the mentioned IoT box (100), and the communication equipment and of course – the method and type of embedded sensors/modules; do the modules (10.i) use a separate power supply or the power supply of the box itself. In a basic version, the power supply is a battery, but it can also be performed as an external power supply from the network, power supply by a solar panel or in any other way known in the state of the art that is adequate for the declared and designed consumption of the IoT modular box itself.

The connection unit (50) is implemented as an independent unit or as one of the modules (10.i) attached to the list of I2C devices of the IoT box itself. This connection unit allows the IoT box (100.k) to be actively connected to the gateway (300.l), l = 1, 2, ..., Q which has a compatible radio module with the connection unit. In the event that the IoT box is predominantly a sensor box that sends sensor data that varies slowly in time, then LoRaWAN-type gateways are suitable, keeping in mind the circuit consumption, system autonomy, and the reach of LoRaWAN communication technology, which is measured in kilometers, and outdoors as much as 10- 15 km from the IoT device to the gateway. In some well-defined technological or technological-business environment where the power supply of the IoT box is not a problem, the likely way of communication of the IoT box with the gateway is a stable WiFi radio module or Low Energy (LE) Bluetooth technology as the two most common robust industry standards.

In addition to all of the above, the IoT box is equipped with at least one verification module (60) performed also as an independent unit or as one of the modules (10.i) that is attached to the list of I2C devices of the IoT box itself. According to variants of the subject invention, this verification module (60) is realized either as a Bluetooth Low Energy (BLE) radio module / technology https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) or as one of the NFC modules, see the link at: https://en.wikipedia.org/wiki/Near-field_communication. The role of this verification module is to enable an external hand-held verification device (200) to have reliable short-range two-way communication with the IoT box in which it is installed in order to perform service or reconfiguration of the IoT box in question. An example of such communication is shown in drawing 2 where a hand-held verification device (200) in the form of a mobile phone is equipped with an external NFC module (210) designed for data exchange with the verification module (60) of the IoT box.

Subject IoT boxes (100.k), where k = 1, 2, ..., P are designed to work in the system shown in drawing 3. The mentioned system or platform for continuous monitoring of the work of modular IoT boxes (100.k) with P modular boxes, k = 1, 2, ..., P, consists of a server (500), a monitoring console (600) of the system itself that is monitored by the operator, at least one verification device (200) and a series of gateways (300.l), l = 1, 2, …, Q. Each IoT box (100.k), as described above, is connected via its radio module to at least one gateway (300.l) with which it can actively, according to the previous definition and needs, exchange data from the module (10.i) to the server (500) and vice versa. This communication can be normal or encrypted, which depends on the architecture of the system itself and the wishes of the client.

As is known in the state of the art, such systems are designed in such a way that:

- each of the mentioned verification devices (200) communicates, in a unit of time, only with one IoT box (100.k) and system server (500),

- that the series of gateways (300.l) is the same or mutually different and chosen from the group consisting of: Wi-Fi, LoRaWAN or Bluetooth Low Energy gateways, and where said gateways are compatible with built-in IoT boxes (100.k) with which they are connected and enabling a reliable connection of boxes (100.k) with the server (500) via the Internet (400),

- that the system records in time the state of each of the modules (10.i) installed in a box (100.j) and monitors the state of all configuration changes of the mentioned modules in each IoT box, and maintains service lists about which it reports to the operator of the monitoring console (600) , you

- that the system enables third parties to communicate with the server (500) for further analysis and management of data that is loaded into or read from the module (10.i) by the IoT boxes (100.j) themselves, and for the purpose of monitoring processes related to the aforementioned boxes (100.j).

The above system communication with third parties is essential for the wide and centralized application of such a system in Industry 4.0. Namely, this communication takes place in such a way that the interested persons, if they have the appropriate security authority, connect to the server (500) and manage the data coming from the module (10.i), enter data into such modules (10.i) that are placed in the boxes over which they have control, or configure and design changes to the sensor/modular content of said boxes through authorized persons and other personnel equipped with verification devices (200). According to one of the aspects of the invention, all verification devices (200) are also equipped with a location service, which at each connection with a verification module (60) of a certain IoT box (100.k) forwards, as a control element, to the server (500) and the location where the IoT box (100.k) is read, and in the absence of a GPS signal, triangulation of mobile operators' signals is used to determine the approximate location of the IoT box (100.k) in service mode. The latter prevents unauthorized changes to the position of the box, as well as reliable reconfiguration of the system.

It is clear that the system described above is easily used in industrial processes of data acquisition from many IoT sensors, industrial automation where it is necessary to manage industrial processes from a separate place, in industries that use redundant safety systems of sensors and control, robotics, telecommunication services and all other processes that include IoT modules that function via the I2C protocol. However, the most important thing about the system has not been said so far, and that is the security aspect that is built into this system and that represents the subject invention. This security aspect is contained in the way each IoT box system works. According to the present invention, each of the boxes is designed for one of the three possible modes of operation discussed below.

In normal operation, the data processing unit (40) of the IoT box in question is configured as a master that communicates with the i-th module (10.i) configured as a slave with a frequency previously defined for the given module (10.i) and it is locally stored in the module frequency list (LFM), written into the memory of the data processing unit. For example, if it is an ambient temperature sensor for which it is not realistic to expect drastic changes in a unit of time, it is quite plausible that a value of 1 minute should be entered for that sensor in the LFM list, as a period during which the system updates the value of such a sensor. For industrial processes that include, for example, AVG (automated guided vehicle) systems inside warehouses, the sensor must have responses of the order of 10 ms. Regardless of the specified LFM list, in the very phase of communicating with the modules:

- or the read value from the module (10.i) is forwarded via the connection unit (50) via one of the compatible gateways (300.l) to the server (500),

- or the previously received value for the i-th module from the server (500), and stored in the memory of the data processing unit (40), is written into the register of the module (10.i) in order to perform the function of the mentioned module (10.i).

It is clear to the average expert in the field that the choice of the connection unit (50) as well as the choice of the compatible gateway (300.l) in such a scheme plays a secondary role, all in order to prevent problematic latency in the two-way communication to the server (500).

In the verification mode, the data processing unit (40) scans all available addresses (11.i) of the connected modules (10.i). In the state of the art, such a procedure is described in a review paper related to Arduino: https://create.arduino.cc/projecthub/abdularbi17/how-to-scan-i2c-address-in-arduino-eaadda, where the so-called I2C Scanner Arduino Code. In a similar or the same way, this can be achieved with other microcontrollers, but the "complication" becomes somewhat greater when, optionally, one or more multiplexers (31) of an IoT box are included in the scanning process. Basically, the read list of available addresses is saved locally as the L1 list and compares the net read L1 list with the previously saved L0 list. Here now there are several variants according to the invention, variants (i) and (ii), described below.

(i) If list L1 is different from list L0, state verification is repeated up to R times and additional lists L2, L3, ..., LR are generated. In the case that all the lists from the set {L2, L3, ..., LR} are different from L0, the data processing unit (40) reports, via the connection unit (50), the server (500) about the read error on the box (100. k) and the need for physical service or control of the box assemblies (100.k). If at least 50% of the value of the list selected from {L2, L3, ..., LR} is identical to the initial list L0, then the data processing unit (40) reports, via the connection unit (50), the server (500) about the transient difficulty of the system and continues writing or writing data to/from the module (10.i) in normal mode.

(ii) If list L1 is the same as list L0, then the data processing unit (40) reports, via the connection unit (50), the server (500) about the normal functioning of the box (100.k) and continues with writing or printing data in/with module (10.i) in normal mode.

In this last case, this verification mode is activated either periodically or via the verification module (60) activated from the immediate vicinity of the box itself (100.k).

This verification mode of operation, apart from self-diagnostics, does not allow changes to the used IoT modules (10.i) in a box (100.k) without the direct intervention of an external operator and a generated service or other order recorded on the server (500). This mode of operation is important to preserve the integrity of the system, but on the so-called at the software level of implementation without interfering with the issues of I2C standards or standards of used standard available circuits / modules / sensors that are I2C compatible. This is also the difference compared to the previous state of the art.

In the service mode, the first step is to activate that mode by connecting the manual verification device (200) to the verification module (60) of the selected box (100.k). For increased security, the data processing unit (40) contains a list of digitally signed identifiers that must match the verification device (200) used to make the connection - all to prevent unauthorized connection. During this process, the verification device (200) also informs the server (500), and additionally the IoT boxes (100.k) independently inform the server (500) that the service treatment has started on the k-th box. It is clear that the server (500) also checks whether service or reconfiguration was scheduled on that box. After positive identifications, the server (500), through the device (200), reserves a time period T during which the box (100.k) cannot independently perform the verification mode of operation and we can say that it is temporarily disabled for standard operation. At the same time, a predefined modified list of modules L0, replaced by the service technician, with the corresponding reading frequencies of the LFM data made by the service technician on the subject box, via the device (200), is written directly into the memory of the data processing unit (40). Upon completion of the physical part of the service mode on the hardware, the variable T is set to the value T=0 and at least one verification mode is performed. If this verification mode is passable, this information is transmitted via the verification module (60) and displayed on the verification device (200) of the service technician, after which the box operation mode is switched to normal, and the verification device (200) independently informs the server (500) that is the box (100.k) fully operational.

Service protocols and execution of default actions on some of the boxes (100.k) are independently controlled through the control console (600) of the system, where changes that require the highest priority of action can also be entered manually. Such action may include, but is not limited to, enrolling new IoT boxes into the system, deleting IoT boxes from the system, and/or other sensitive actions that require the supervision of a system supervisor.

As mentioned before, all verification devices (200) are equipped with a location service, which, when connected to a verification module (60), transmits, as a control element, the location where the IoT box (100.k) is to the server (500) box (100.k) read. In the absence of a GPS signal, the triangulation of mobile operators' signals is used and thus determines the approximate location of the IoT box (100.k) in service mode, which makes the system itself extra secure and robust. The service mode therefore does not allow independent changes to the system without server supervision (500), and at the same time the location of the IoT boxes in question is checked (100.k).

In further aspects according to the invention, AI (artificial intelligence) can be used to monitor possible failures in the system and assess whether the value read from a module of a box is credible, whether it corresponds to the activity for which it is intended. Such a system is known in the state of the art, see for example the Facebook® Prophet system: https://facebook.github.io/prophet/ and is very useful in independent observation of the behavior of systems over which there is "electronic" supervision.

Industrial applicability

From everything written so far, it is clear that the subject IoT boxes and the monitoring system itself are especially used in industrial processes of data acquisition from many IoT sensors, industrial automation where it is necessary to manage industrial processes from a separate location, in industries that use redundant safety systems of sensors and management, robotics, telecommunication services and all other processes that include IoT modules that function via the I2C protocol. From the foregoing, it is clear that the industrial applicability of this invention is obvious.

References

10.i Module; i = 1, 2, ..., N

11.i I2C sensor address 10.i

20.j Module slot; j = 1, 2, ..., M

30 Bus, I2C bus

31 Multiplexer for I2C bus

40 Data processing unit

50 Connecting unit

60 Verification module, BLE module or NFC module

70 Power supply

100.k Box; k = 1, 2, ..., P

200 Manual verification device

210 Communication module, eg NFC module

300.l [LoRa or Wi-Fi] gateway; l = 1, 2, ..., Q

400 Internet

500 servers

600 Monitoring console

Claims (10)

1. The operation procedure of a modular IoT box (100.k) within a system with P modular boxes, k = 1, 2, ... P, where each IoT box (100.k) consists of: - an arbitrary number of slots for modules (20.j), j = 1, 2, ..., M, dimensionally and electrically designed to accept an arbitrary number of modules (10.i), i = 1, 2, ..., N; where N ≤ M, where all modules are designed to communicate with the I2C communication protocol in such a way that they have their own unique I2C address (11.i), - where modules (10.i) are arbitrarily chosen from a set of I2C devices without restrictions, and in particular from a group of different sensors, analog-to-digital converters (ADP) and digital-to-analog converters (DAP), radio modules as well as data display modules, - buses (30), designed to connect modules (10.i) operating in slave mode by appropriate wiring with a data processing unit (40) configured to operate in master mode, - optionally, one or more multiplexers (31) installed on the bus that allow the use of two or more modules with the same purpose and the same built-in I2C address in such a way that the data processing unit (40) sees them as a set of completely different modules (10.i ) with a different I2C address (11.i) within the same I2C connection scheme, - where the data processing unit (40) is additionally connected to the connection unit (50) and at least one verification module (60) which is performed either independently or as one of the modules (10.i), where the purpose of the unit (40) is processing of signals received from the mentioned modules (10.i) or controlled by the behavior of individual modules (10.i) and verification module (60), and establishing communication via the connection unit (50) with the external server of the system (500), where the mentioned IoT box (100.k) prevents arbitrary modification or addition of modules (10.i) in the slots (20.j) it monitors, and performs self-diagnostics, in such a way that the mentioned box (100.k) executes one of three possible modes of operation, indicated by the fact that these modes are selected from: the normal mode of operation when the modules (10.i) communicate with the server (500) via the mentioned box (100.k) in the initially set time periods defined by the frequency list of the built-in modules (LFM ), the verification mode of operation when the functionality and the number of installed modules are determined (10.i), and the service mode that enables the reconfiguration of the box in question (100.k) and the modification of the module (10.i) by the operator. 2. The method of operation of the modular IoT box (100.k) according to claim 1, characterized in that in the normal mode of operation the data processing unit (40) is configured as a master that communicates with the ith module (10.i) configured as a slave with the frequency that was previously defined for the given module (10.i) and is locally stored in the list of frequencies (LFM), and in the communication phase: - or the read value from the module (10.i) is forwarded via the connection unit (50) via one of the compatible gateways (300.l) to the server (500), - or the previously received value for the i-th module from the server (500), and stored in the memory of the data processing unit (40), is written into the register of the module (10.i) in order to perform the function of the mentioned module (10.i). 3. The operation procedure of the modular IoT box (100.k) according to claim 1, characterized by the fact that in the verification mode, the data processing unit (40) scans all available addresses (11.i) of the connected modules (10.i), read saves the list of available addresses locally as list L1 and compares the read list L1 with the previously saved list L0, and if: (i) L1<>L0 repeats state verification up to R times and generates additional lists L2, L3, … LR, and in case all lists from the set {L2, L3, …, LR} are different from L0, the data processing unit ( 40) reports, through the connection unit (50), the server (500) about the error read on the box (100.k) and the need for physical service or control of the box assemblies (100.k); and if at least 50% of the value of the list selected from {L2, L3, ..., LR} is identical to the list L0, then the data processing unit (40) reports, via the connection unit (50), the server (500) about the transient difficulty of the system and continues writing or writing data to/from the module (10.i) in normal mode; or (ii) L1 = L0 the data processing unit (40) reports, via the connection unit (50), the server (500) about the normal functioning of the box (100.k) and continues to write or write data to/from the module (10 .i) in normal operation mode, where the verification mode is switched on either periodically or via the verification module (60) activated from the immediate vicinity of the box itself (100.k). 4. The operation procedure of the modular IoT box (100.k) according to claim 1 and 3, characterized in that the service mode is activated by connecting the manual verification device (200) to the verification module (60) of the selected box (100.k), whereby the unit for data processing (40) contains a list of digitally signed identifiers that must correspond to the verification device (200) used to make the connection in order to prevent unauthorized connection, whereby the verification device (200) informs the server (500) and additionally the IoT boxes (100. k) independently informs the server (500) that service treatment has begun on the k-th box, after which the server, via the device (200), reserves a time period T during which the box (100.k) cannot independently perform verification mode, and in advance the defined modified list of sensors L0 with the corresponding frequencies of LFM data readings made by the service technician on the box in question, through the device (200), is written directly into the memory of the data processing unit (40), after which the variable T is set to the value T=0 and at least one verification mode is performed, which - if it is transitory, is transmitted via the verification module (60) and displayed on the verification device (200) of the service technician, after which the box's mode of operation is switched to normal, and the verification device (200) informs independently server (500) that the box (100.k) is fully operational. 5. The operation procedure of the modular IoT box (100.k) according to one of claims 1, 3 or 4, characterized in that the verification module (60) is selected from the group consisting of NFC or Bluetooth® Low Energy circuit that enables two-way communication between the verification module (60) and verification device (200). 6. The operation procedure of the modular IoT box (100.k) according to claim 5, characterized in that the verification device (200) is a mobile device equipped with a compatible circuit for communication with the verification element module (60) of the IoT box. 7. The method of operation of the modular IoT box (100.k) according to any of the preceding claims, characterized in that the connection unit (50) is selected from WI-FI, LoRaWAN and Bluetooth Low Energy radio modules, preferably LoRaWAN modules, performed or as an independent module connected to the data processing unit (40) or as one of the modules (10.i) of the aforementioned IoT box (100.k). 8. System for monitoring the operation of modular IoT boxes (100.k) with P modular boxes, k = 1, 2, ..., P, consisting of a server (500), a monitoring console (600) of the system itself, at least one verification device (200) and series of gateways (300.l), l = 1, 2, …, Q, where each IoT box (100.k) consists of: - an arbitrary number of slots for modules (20.j), j = 1, 2, ..., M, dimensionally and electrically designed to accept an arbitrary number of modules (10.i), i = 1, 2, ..., N; where N ≤ M, where all modules are designed to communicate with the I2C communication protocol in such a way that they have their own unique I2C address (11.i), - where modules (10.i) are arbitrarily chosen from a set of I2C devices without restrictions, and in particular from a group of different sensors, analog-to-digital converters (ADP) and digital-to-analog converters (DAP), radio modules as well as data display modules, - buses (30), designed to connect modules (10.i) operating in slave mode by appropriate wiring with a data processing unit (40) configured to operate in master mode, - optionally, one or more multiplexers (31) built into the bus that allow the use of two or more modules with the same purpose and the same built-in I2C address in such a way that the data processing unit (40) sees them as a set of completely different modules (10.i) with a different I2C address (11.i) within the same I2C connection scheme, - where the data processing unit (40) is additionally connected to the connection unit (50) and at least one verification module (60) which is performed either independently or as one of the modules (10.i), where the purpose of the unit (40) is processing of signals received from the mentioned modules (10.i) or controlled by the behavior of individual modules (10.i) and verification module (60), and establishing communication via the connection unit (50) with the external server of the system (500), indicated that: - each of the mentioned verification devices (200) communicates, in a unit of time, only with one IoT box (100.k) and system server (500), - that the series of gateways (300.l) is the same or mutually different and chosen from the group consisting of: Wi-Fi, LoRaWAN or Bluetooth Low Energy gateways, and where said gateways are compatible with built-in IoT boxes (100.k) with which they are connected and enabling a reliable connection of boxes (100.k) with the server (500) via the Internet (400), - that the system records in time the state of each of the modules (10.i) installed in a box (100.j) and monitors the state of all configuration changes of the mentioned modules in each IoT box, and maintains service lists about which it reports to the operator of the monitoring console (600) , you - that the system enables third parties to communicate with the server (500) for further analysis and management of the data that is loaded into or read from the module (10.i) in the IoT boxes (100.j) for the purpose of monitoring the processes related to the mentioned boxes (100 .j). 9. A system for monitoring the operation of modular IoT boxes (100.k) according to claim 8, characterized by the fact that all verification devices (200) are equipped with a location service, which at each connection with a verification module (60) of a certain IoT box (100. k) forwards, as a control element, to the server (500) the location where the IoT box (100.k) was read, and in the absence of a GPS signal, mobile operator signal triangulation is used and thus determines the approximate location of the IoT box (100.k) in the service area mode of operation. 10. Use of a modular IoT box (100.k) with the functionality described in claims 1-7, which is located within a system with P modular boxes, k = 1, 2, ... P, defined by claim 8 or 9, characterized by the fact that it is particularly used in industrial processes of data acquisition from many IoT sensors, industrial automation where it is necessary to manage industrial processes from a separate place, in industries that use redundant safety systems of sensors and control, robotics, telecommunication services and all other processes that include IoT modules that function via I2C protocol.