HRPK20192293B3 - Method of iot platform operation for acquisition, processing and tracking, analysis, control and optimisation of measuring data and for control and surveillance of devices - Google Patents

Description

1.1 Field of the invention

The subject invention relates to the Internet of Things (IoT) used as a platform for collecting, processing and monitoring, analyzing, controlling and optimizing measured data and for managing and monitoring devices. The system is designed in such a way as to enable adaptation to different user profiles; for example, to those who use only energy sources, to those who use and redistribute them, including those who monitor the processes themselves, say supply and drainage - for example, if it is about water as a process parameter. The platform according to the subject invention is integrated, if necessary, with systems for advanced support for planning, preparation, execution and monitoring of operational deliveries of products, services and projects and support for managing the value chain of a business organization in real time.

1.2 Technical problem

The subject invention was conceived in such a way as to solve the IoT problems observed in the state of the art. The technical problems solved by the system in question are listed below and consist of:

- creation of a unified interface and database of all energy sources in production and/or application;

- standardization of consumption at the level of the production unit and/or production process;

- signaling and notifying users in case of deviations from previously defined parameters;

- quickly obtaining the necessary information and making decisions based on data in real time;

− the possibility of estimating future consumption that is handed over to energy suppliers, for example in the case of gas or overhead costs of water;

− the ability to monitor energy consumption in production with the ability to monitor key process parameters;

− possibilities of integration of several lines, production departments or factories into one logical unit of monitoring;

- a centralized display of consumption by all facilities in different locations, eg for different organizational units (multiple hierarchies); and finally,

- collecting data on the production of renewable energy sources and evaluating the efficiency of individual units such as solar panels, wind farms and other renewable sources.

1.3 Prior art

The prior art is extremely rich in different solutions that usually address only part of the above-mentioned problems. Some of the state of the art documents are listed below.

WO2018/026964A1 for the invention entitled DISTRIBUTED RESOURCE ELECTRICAL DEMAND FORECASTING SYSTEM AND METHOD where the behavior of the electricity supply system is analyzed and predicted.

US2018/347763A1 for the invention is called MACHINE LEARNING DETECTION OF PIPELINE RUPTURES, which teaches the method of detecting pipe ruptures based on machine learning and monitoring consumption or measurement parameters.

US2018/132015A1 for the invention INTEGRATED SOLUTION OF INTERNET OF THINGS AND SMART GRID NETWORK PERTAINING TO COMMUNICATION, DATA AND ASSET SERIALIZATION, AND DATA MODELING ALGORITHMS refers to the monitoring of behavior within the network with a multitude of input sensors and prediction of behavior based on the so-called "big data" analytics.

US2014/303935A1 for the invention UNIVERSAL INTERNET OF THINGS CLOUD APPARATUS AND METHODS, which addresses the problems of analytics and control of devices via cloud servers and business decision-making arising from them.

Quite a number of scientific works have been published in the technical field of the subject invention; some, purely as an example, we list here below.

K. Chooruang and K. Meekul: DESIGN OF AN IOT ENERGY MONITORING DESIGN OF AN IOT ENERGY MONITORING SYSTEM; 2018 Sixteenth International Conference on ICT and Knowledge Engineering;

DOI: 10.1109/ICTKE.2018.8612412

D. Dobrilovic, M. Milan, D. Malic: LEARNING PLATFORM FOR SMART CITY APPLICATION DEVELOPMENT; Interdisciplinary Description of Complex Systems 17(3-A), 430-437, 2019;

DOI: 10.7906/indecs.17.3.1

S. U. Alam, R. Ahmed, M. S. Imam, M. Farshid, M. A. Hossain, and M.A. Islam: DESIGN AND IMPLEMENTATION OF WEBSITE BASED ENERGY CONSUMPTION MONITORING AND CONTROLLING; Conference: 2019 International Conference on Computer Communication and Informatics

DOI: 10.1109/ICCCI.2019.8821978

It appears that in the state of the art, to the inventor's knowledge, there is no system that is equal to the system described in detail here in terms of accuracy, signaling and reporting to the user and predictive capabilities.

1.4 The essence of the invention

The invention discloses the operation procedure of an IoT (Internet of Things) platform for collecting, processing and monitoring, analyzing, controlling and optimizing measured data and for managing and monitoring a multitude of measuring devices. The platform consists of one or more gateway components, message brokers, optionally one or more ERP systems, firewalls, frontend components, backend components, authentication servers and database servers organized in the industrial part of the network (I) and the system located in the cloud (C ) with software support for the components listed above. At least one client accessing the system in the cloud (C) is required for the system to work.

The industrial part of the network (I) contains one or more gateway components connected by a firewall to the part of the system located in the cloud (C). A plurality of measuring devices, each of which is connected to only one gateway component, converts the analog measurement quantity into a digital one and forwards it to the gateway component to which it is assigned and which communicates with the message broker located in the cloud part of the system (C).

The cloud system (C) monitors the industrial part of the network (I) using the backend server, which is the main component of it, and which executes all the business logic. The backend server is connected via message brokers and firewalls located on the cloud system side (C) to the firewall placed in front of the mentioned gateway components of the industrial part of the network (I). The cloud system (C) also has a frontend server whose program support is used to display data from the backend server to which it is connected. One or more clients of the system access data through the firewall to the previously mentioned frontend server with the support of the authentication server in charge of authorizing access to system data by users to the backend server (70).

The database server (90) performs storage and preservation of all system data generated over time; from the data of measuring devices, access time, system health up to the time of data access by each of the clients.

According to the subject invention, the system is designed in such a way that:

- each client accesses the cloud system (C) through a unified interface with restrictions in the way data is displayed and manipulated previously recorded on the authentication server and with restrictions on the available measured data defined on the backend server, whereby the cloud system (C) adjusts the graphical display of the system state to the physical client device,

- the cloud system (C) signals and informs the client in case of deviation of one or more measuring devices under the supervision of the mentioned client from previously defined parameters; you

- the cloud system (C) enables the integration of multiple measuring devices into structural units, computationally, based on data from two or more measuring devices.

The structural units in the subject invention are related: to the territory, to the type of process being monitored, or to a combination of process and territory; and optionally with a defined hierarchical structure. Each hierarchical structure is changeable in such a way that the client can independently change and adapt it to his own analytics if he has the permission of the authentication server for such action in the system.

The system is designed in such a way that it enables viewing and monitoring the correlation of two variables in time; where each of the mentioned variables is selected from a set consisting of: a measuring device, a structural unit of measuring devices or only a part of a structural unit. In one variant according to the invention, the structural units are spatial zones selected beforehand on the graphical interface by the client. For reliability, the cloud system (C) signals and informs the client (100) about the state of the system at pre-defined time intervals by automated reports sent through pre-selected communication channels.

1.5 Description of images

The entire system is described with images that illustrate both the system architecture and the software support options included in the aforementioned architecture. The description of the pictures is given below:

Figure 1 shows the system architecture.

Figures 2A-2D show the quick view and global search specified by Example 1 and Example 2.

Figures 3A-3H illustrate Example 3 - user management.

Figures 4A-4B illustrate Example 4 - user group management.

Figures 5A-5F illustrate Example 5 - grouping measuring devices into hierarchies.

Figures 6A-6D illustrate Example 6 - managing data viewing rights.

Figures 7A-7R illustrate Example 7 - dashboard and tabs (widgets).

Figures 8A-8K illustrate Example 8 - Time Filters.

Figures 9A-9L illustrate Example 9 - Graphical Reports.

Figures 10A-10D illustrate Example 10 - Correlation Analysis.

Figures 11A-11H illustrate Example 11 - Incoming Data Reports.

Figures 12A-12C illustrate Example 12 - Threshold Report.

Figures 13A-13H illustrate Example 13 - Device Status Report.

Figures 14A-14C illustrate Example 14 - Meter Status Report.

Figures 15A-15F illustrate Example 15 - Management of periodic sending of reports (SCHEDULING).

Figures 16A-16D illustrate Example 16 - Company and Device Location Setup.

Figures 17A-17D illustrate Example 17 - Location Reports.

Figures 18A-18K illustrate Example 18 - Zones.

Figures 19A-19D illustrate Example 19 - Predictive Models and Analytics.

1.6 Detailed description of the invention

The subject invention relates to the IoT (Internet of Things, see https://en.wikipedia.org/wiki/Internet_of_things) platform for collecting, processing and monitoring, analyzing, controlling and optimizing measured data and for managing and monitoring devices. The system was designed and implemented in such a way as to enable adaptation to different user profiles; for example, to those who use only energy sources, to those who use and redistribute them, including those who monitor the processes themselves, say supply and drainage - for example, if it is about water as a process parameter. The platform according to the subject invention is integrated, if necessary, with systems for advanced support for planning, preparation, execution and monitoring of operational deliveries of products, services and projects and support for managing the value chain of a business organization in real time.

The solution according to the subject invention is a turnkey system from data collection to their analysis and planning of future consumption as well as comparison with entered target values in real time. The solution provides support for all the most commonly used types of energy sources, manufacturers of meters and sensors, as well as for data transfer mechanisms and data protocols that make this system possible.

Some of the advantages of the system architecture presented here are:

- unified interface and database of all energy sources in production or application;

- standardization of consumption at the level of the production unit and/or production process;

- signaling and notifying users in case of deviations from previously defined parameters;

− quickly obtaining the necessary information and making decisions based on data in real time;

− the possibility of estimating future consumption that is handed over to energy suppliers, for example in the case of gas or overhead water costs;

− the possibility of monitoring energy consumption in production with the possibility of monitoring key process parameters;

- the possibility of integration of several lines, production departments or factories into one logical unit of monitoring;

- centralized display of consumption by all facilities in different locations, through different organizational units (multiple hierarchies); and finally,

- collection of data in the production of renewable energy sources and assessment of the efficiency of individual units such as solar panels, wind farms and other renewable sources.

The platform is designed to be able to work with any type of measurement and discrete data (signals) and in this sense, the standard IoT platform is mainly focused on cost saving opportunities with direct application to a wide range of business processes.

The following are identified as end users of this platform:

- processing and manufacturing industry,

- catering,

- distribution, logistics and transport, sales,

- offices, and local and public administration (construction).

The next group of users are service providers, especially utility distribution systems (water, gas, electricity, ...), and companies that deal with facility management. Somehow, at the very end, there are also socially conscious companies that care about the environment and strive for certification or are in the process of re-certifying ISO 50001 [Energy efficiency] or ISO 14001 [environmental management system].

The architecture of the system is shown in Figure 1. The system consists of the industrial part of the network (I), the cloud system (C) in which all the necessary actions take place, and external clients - users of the system in question.

Industrial part of the network (I)

The industrial part of the network (I) consists of a multitude of measuring devices (10) located at defined physical locations (k) of which there can be an arbitrary number. We will label such measuring devices without any specific location-related number; in such a way that each measuring device has its own ID; eg (10.123), while within the system, in the cloud (C), the location of the device itself will be recorded. The used measuring devices (10.i) consist of a measuring probe or another type of device (e.g. a counter) that digitizes the analog physical quantity with sufficient accuracy for the needs of the measuring location. Furthermore, the measuring devices have electronic circuitry (hardware) that enables the measured quantity to be forwarded, via the selected protocol and information carrier, to one of the gateways (20.k). By the English term "gateway" we mean a device for connecting two systems that uses different protocols.

In the implementation, the system is designed to be flexible enough that the number and method of connection of measuring devices (10.i) to a gateway (20.k) allows freedom in architecture, compatibility and the use of all industrial standards; wired, wireless, redundant if required by the measuring site with appropriate communication protocols. Measuring devices can be any selected from the group consisting of: water meters, gas meters, electricity meters, ..., up to specific measuring points that measure, for example, humidity, temperature, insolation, etc. There are no restrictions regarding the character of the data that can be an input measurement quantity. The platform itself is designed in such a way that the only condition is that at some point the measuring device (10.i) delivers digital information representing the "measurement" of some monitored variable to the system itself. The multitude of measuring devices represents an essential part of the IoT structure that forms the basis for the realization of the subject invention.

Each gateway component (20) is developed as an independent component for each location and/or company where the platform according to the subject invention is used. Gateway components (20.k) are automatically logged into the network via the Service Discovery protocol. They continuously read or receive data from different types of measuring devices (10.i). Upon receiving or reading a device (10.i), the gateway component (20) parses the received message using a parser by type of measuring device. Parsing or syntax analysis is used to adequately structure the read data. The parser itself can be dynamically changed and transmitted over the network, which makes the gateway components (20) highly adaptable depending on the devices to be read. After the specific gateway component (20) receives and parses the message, the message is translated in the parsing process into a standardized reading format suitable for sending to the backend component (70) of the system. It is desirable to design the system in such a way that each gateway component (20) aggregates the readings into one larger message which is then periodically sent, thereby optimizing the use of network resources. Some of the advantages of such gateway components (20) are listed below:

a) The gateway component (20) is arbitrarily extensible with new parsing scripts, this enables the gateway component (20) once placed in a location to be relevant in the long term for data collection and processing.

b) The Gateway component (20) can be installed in situ or on the cloud.

c) In the event of an Internet access failure, the gateway component (20) in situ continues to perform its work and forwards messages after Internet access is restored.

d) In the event of a server failure of the gateway component (20), the gateway automatically reads its configuration after restarting and continues operation.

e) The IP address of the gateway component (20) can be changed, the components discover each other through the Service Discovery component of the system.

f) It is possible to aggregate readings to reduce server load.

The industrial part of the network (I) contains, in addition to the previously mentioned multitude of measuring devices (10.i), several gateway components (20.1, 20.2, ...), which are connected by a firewall (50) to the part of the system located in the cloud. The role of the firewall (50) is to filter network traffic so that a security zone is created, in this case towards the industrial part of the network (I). Optionally, it is possible to implement within the industrial part of the network (I) one or more ERP systems (40) (Eng. Enterprise Resource Planning) in the form of computers running business software aimed at integrating the activities of different departments; for example procurement, inventory management, product distribution, order tracking and production, etc. The ERP system (40) makes decisions that are partly based on data collected from one or more gateway components (20.1, 20.2, ...) that monitor a selected set of measuring devices (10.i, 10.i+1, ...), of course, if such input into the ERP system (40) is useful.

Cloud system (C)

Data inputs and outputs to the system located in the cloud (C) are protected by an appropriate firewall (50', 50“); see figure 1.

When we look at the architecture of the part of the system located in the cloud (C), Figure 1, it consists of the following basic components: authentication server (80), frontend server (60), backend server (70), message broker (30) and server with database (90).

All components discover each other using Service Discovery, as well as the previously described gateway components (20), and the components do not know about each other's positions except for the position of the Service Discovery server. When the components are started, they log on to the main Service Discovery server, which then maintains the so-called "health check" according to the components and records the state of the entire system. This approach enables greater resilience to outages, easier horizontal scaling and a higher level of system availability. Communication between components takes place using REST (eng. REpresentational State Transfer, prescribed architecture of network services) over SSL (eng. Secure Sockets Layer) using the OAuth2 industry standard for authorization and authentication; see more at https://oauth.net/2/

The backend server (70) is the main component that executes the business logic of the system. This component takes all the readings from the message broker (30) to which the gateway components (20.k) delivered data from the measuring devices (10.i), and via a series of firewalls (50, 50'). When retrieving readings, the backend server (70) checks for critical alarms on those readings. If they exist, the backend server (70) triggers default alarms that are sent to the clients via the selected communication channel; e.g. via e-mail, SMS, or direct display in the application - which we will discuss later.

The processing of the received readings itself is an important part of the overall system, and considerable time was devoted to optimizations and improvements of this processing during its creation. Some of the more significant program solutions within processing in the backend server (70) are listed below:

a) Data from measuring devices (10.i) that arrive with a delay, and there is already a more recent data than the currently received one, initiate data reprocessing from the moment before the delayed data. This ensures the highest degree of accuracy of processed data.

b) The processing determines the state of the counter or gauge once every quarter of an hour, this means that the processing evaluates what state the meter would be in when it was read exactly at the quarter of an hour. The mentioned option is necessary because the reading dynamics do not necessarily correspond to the reporting dynamics. The processing uses existing and historical data to approximate the situation in a quarter of an hour and possibly detect a problem in the system.

c) In case of data loss for a certain period, the processing reconstructs the data in the period in between using some of the productive methods known in the state of the art; from simple interpolations to more complex neural networks.

The frontend server (60) and the corresponding frontend application - program logic - serves to display data from the backend application. It is the main interface used by the user, who is behind the firewall (50“) and accesses the frontend server (60) through his own system or device (100). The frontend application is designed flexibly and supports different device resolutions, including mobile devices. Due to the small size of mobile screens, certain functionalities on mobile devices are not enabled, of which the user (client) has been informed in advance.

Message broker (30) (eng. message broker or integration broker) is a computer program (system component), which is started on the selected computer, with the role of receiving messages from other applications or system components and managing these messages. As explicitly stated at https://en.wikipedia.org/wiki/Message_broker, an example of using a message broker is managing a workload queue or message queue for several different recipients, enabling reliable storage and guaranteed delivery of messages and management of the message transaction scheme in its entirety.

The authentication server (80) is responsible for authorizing access to system data by users/clients (100) towards the backend server (70). The role of the database server (90) is to store and preserve all system data in time; from data of measuring devices (10.i), access time, system health up to the time of data access by each of the clients (100.j).

An average expert in the field, according to the scheme shown in Figure 1, can form the previously described system without introducing additional assumptions.

In connection with the data exchange protocols used, it is usual to use HTTPS (Hypertext Transfer Protocol Secure) connection between clients (100.j), through the firewall (50") to the frontend server (60). Likewise, it is preferable to use the mentioned HTTPS for the connection of the frontend server (60) and the backend server (70).

The message broker (30) communicates via AMQP (Advanced Message Queuing Protocol) to the backend server (70) on the one hand, and via the firewall (50') to the gateway components (20.k). AMQP (https://www.amqp.org/about/what) is an open standard for passing messages between applications or organizations. It is used for reliable connection of separated systems.

The database server (90) is connected to the backend server (70) eg TCP/TDS (Transmission Control Protocol (TCP) / Tabular Data Stream (TDS)). The connection to the authentication server is established via OATH2/HTTPS.

If necessary, Microsoft Active Directory (AD) is also used for authentication and authorization of users in the network and management of system security provisions.

Definition of terms used

A device is a physical device that is installed in a specific location to collect data from a series of gauges or sensors.

A measurement made on, for example, a water meter, gas meter, electricity meter, temperature sensor, represents one measured quantity. This can be, for example, a device that was installed to measure water consumption (reads from the water meter) or measure voltage (reads the device's battery). Each measurement data read is assigned to a specific measurement.

Measurement data is data read from a certain measurement, for example the state of a water meter at a certain moment or the state of a temperature sensor at a certain moment.

A virtual measurement is a measurement that was created by calculation on the basis of other measurements, for example it is possible to add data from several water meters in a building to one virtual measurement that represents the entire building.

A manual measurement is a measurement that is entered manually with a certain dynamic; eg an analog water meter that is read manually by entering the well.

Normative is a ratio between two measurements, most often used to express and monitor key performance indicators, for example, the efficiency of a process or the amount of scrap.

A zone is a concept of a geographically limited area that can have input, output or control measurements. For example, using the zone, it is possible to model the DMA zone (Eng. District Metering Area / Croatian isolated metered zone) and use it for analyzes and predictions. Zones can be used on reports in such a way that the platform automatically retrieves all consumption for devices within the zone, after which it is added or subtracted depending on the defined rules and the wishes of the clients.

Location – the measuring location where the devices are located, it is possible to determine which measuring quantities are measured at each of the locations.

Granulation - the level of data grouping, for example "day" granulation means that the data will be summarized to the day level and one data for one measurement for one day will be displayed in the graphs.

Time filter – enables data filtering using periodically defined conditions (eg every night from 1am to 5am). This filter can be used when retrieving any reports.

Specifics: Data is processed for reports for a period of 15 minutes, for reporting purposes all data is processed "live" without intermediate tables that store consumption at the level of day, week, month, quarter or year. This solution provides advanced options for filtering and aggregating data according to different criteria, for example the total consumption in the year for all weekends from 16:00 to 20:00. The use of queries that filter the reporting data every time at the level of 15 minutes allows for certainty about the accuracy of the data.

Common functionalities and implementation examples

The designed system that was previously described enables a multitude of functionalities, from simple to complex. In this section, we will look at some features of the designed system through the prism of user-client experience (100.i). The system will be described with a series of pictures that illustrate the functionality and flexibility of the system in such a way that an average expert in the field (programmer) can, without introducing additional assumptions, form a system of equal functionality with computer programs in interaction, which "spin" on the previously described parts of the system.

Example 1 - Quick overview

On different screen sizes, the system enables quick view functionality. This dashboard functionality can be opened by clicking on the amount in the tabs to display the measurement values. Figure 2A shows an example of a quick overview of consumption. Figure 2B shows an excerpt from the table for a single measuring device (10), specifically a water meter that can be started by selecting a name, for example by clicking on the name within the application that is available to the client.

After opening the quick overview, all details about the open measurement, zone or other data are visible. Here it is also possible to go into details about the components of an individual measurement, figure 2B, zone or virtual measurement using the options for the names of individual items; see example execution in Figure 2C. The quick view also allows changing the graphic display using predetermined periods and granularities. Another option is to click on the edit icon (top right, Figure 2C), which will open a form for editing the specified measurement, zone or other displayed data.

Example 2 - Global search

The system enables the use of global search. This global search searches various objects within the application and offers results depending on the values found. For displayable values (measurements, zones, norms, ...), selecting a name opens a quick overview for those displayable values, and starting the editing icon to the right of the name opens a form for modifying a particular measurement, zone or other entity. An example interface for such global searches is shown in Figure 2D.

Most of the measurement systems that we currently encounter in use contain only these two basic functionalities, which cannot be used in full without the upgrade shown in the examples below, and one of them is certainly the management of users and authorities within the system.

According to the subject invention, each user of the system must have his own user account and clearly defined powers that enable him to work in the system. The user belongs to one or more user groups and through them obtains rights to certain actions in the system (eg creating and/or editing other users, adding new devices, viewing certain reports, etc.). Also, the user can be allowed/denied to see specific devices or measurements using device groups.

Example 3 – User management

To view users, it is necessary to select Management - Users in the left menu of the application, Figure 3A. Users are displayed in a table with their main features. Existing users can be edited or deleted, and by clicking the "add" button it is possible to create a new user as shown by the arrow in Figure 3B. Likewise, to search for users, we enter the search term in the marked field. The search is performed during the entry process itself, as shown in Figure 3C.

The columns that are displayed in the table with users can be selected by clicking on the drop-down menu as shown in Figure 3D.

When adding a new user, we enter the user's first name, last name, username and password. It is also necessary to choose the language in which the user interface will be displayed, which the user can later change himself, and to choose whether we want the user to be active or inactive ("User State"). A user entered as inactive or later deactivated cannot log into the system until this setting is changed. The setting of these settings is shown in Figure 3E, where the "user state" is indicated by a color, eg green for active as in Figure 3E which is seen here as a dark slider background. One or more user groups must be selected from the "User groups" drop-down menu, and each group carries with it rights to certain functions in the system; as shown in Figure 3F.

Selecting the device authorization group gives the user rights over certain devices and measurements, see Figure 3G. For details on the hierarchy of device groups, more will be said in one of the following chapters. When all the settings are selected, it is necessary to save the user by clicking the "Save" button. The new user will be displayed in the user table and, if he is defined as an active user, he can log in to the system and start using the system; as seen in Figure 3H.

Example 4 – Managing user groups

To manage user groups, it is necessary to click Management - User groups in the left menu. Similar to users, it is possible to search the list of groups, select the displayed columns and edit, delete or add a new user group; see Figure 4A. On the form for entering or editing a user group, it is necessary to enter the name and description of the group and add one or more authorizations from the drop-down menu; see Figure 4B.

Example 5 – Grouping measuring devices into hierarchies

The system according to the subject invention enables the definition of a hierarchy of device groups with an arbitrary number of hierarchy levels. Each device group can contain one or more devices, and each device can contain one or more measurements. Device groups are used to grant rights to users. The user thereby "sees" all devices and measurements that are below the assigned user level for the user in question. Device groups are accessed by selecting: Configuration – Devices – Device Hierarchy, in the left menu as shown in Figure 5A.

If we want to add a group of devices at the very top of the hierarchy, we can do so through the option "Create initial group", and if we want to create the same at any other level, we select the group of devices for which we want to be superior to the new group and use the option "Add device group" next to the selected parent group; see Figure 5B. In both cases, the entry of the device group is the same: we enter the name, description and status (active/inactive) and click "Save"; Figure 5C. This creates a new group of devices that is displayed in the hierarchy at the place where it was added; see the situation shown in Figure 5D. In Figure 5E we see the complete hierarchy of devices and measurements. Devices and measurements are marked with a different icon than a device group. Devices are always subordinate to device groups. The proposed system enables moving in the hierarchy of groups of devices using the so-called drag-and-drop (D&D) functionality; see Figure 5F where, for example, a group of devices from the same street is switched by D&D mode. In this way, we can organize devices in the system and allow specific users access to a specific group of devices at any level.

Example 6 - Management of rights to view data

The management of authorizations for viewing data is also one of the more interesting functionalities of the system. In order to connect users and groups of devices, in the left menu, select Configuration - Devices - Device group authorization. In order to add a new authorization, it is necessary to click on the "Add" button, as shown in Figure 6A. Enter the Name and Description of the new authorization on the form. In the right column of the "Device groups" section, we add device groups to which this authorization applies. Adding is done by clicking on the group in the left column and it is moved to the right column, Figure 6B. The system allows very simple and intuitive addition and removal of groups, which we do by switching from the left to the right column and vice versa, see Figure 6C. In a similar way, we add users to the right column of the "Users" section in order to connect them to selected groups of devices; see Figure 6D.

Example 7 - Dashboard and tabs (widgets)

The system according to the present invention enables the addition of various tabs (eng. Widget) to the dashboard. The cards are used to display data about measurements, KPIs (eng. KPI - key performance indicators), but also device statuses and device locations and labels at locations. Figure 7A shows a multi-tab dashboard. The user has the option of reducing or increasing individual cards on the board, and moving or rearranging cards on the dashboard with the D&D system, see Figure 7B.

When adding a new card to the dashboard, the user must first select the type of element, i.e. card. After selecting the element, it is necessary to define display settings for each type of card. Settings vary from type to type. Figure 7C shows such an example of a menu for selecting elements. Once the element is selected, it is possible to compare the current measurement value with an earlier period, see Figure 7D.

In the described way, it is possible to generate a number of additional tabs on the control panel, for example, as shown in Figure 7E.

When you want to work with KPI, similar to the measurement display card, you need to select the measurement, then define whether you want the KPI of the measurement value or the amount of consumption in currency, and select the month for which you want to observe the KPI; see Figure 7F.

The subject system also enables the generation of cards for table display. For the tabular display of measurements, it is necessary to select one or more measurements, and on the display we will get a table with the amounts of measurements, for example by individual months in the current year; see Figure 7G. The layout of the dashboard card is shown in Figure 7H.

The system also enables cards focused on graphic display, for example, generating a line graph that represents a simplified variant of graphic analysis. To start it, you need to select:

- one or more measurements;

- set the grouping of measurement points (year, quarter, month, week, day, hour or quarter of an hour); you

- time period from the drop-down menu.

Figure 7I shows the selection mentioned above, and Figure 7J shows the result - the appearance of the tab on the control panel.

It is possible to create a circular graph in an identical way; see Figures 7K and 7L; that is, the bar graph, see Figures 7M and 7N.

The system also provides cards for device locations. For this card, it is necessary to adjust the map so that it shows the area we want. If we want to see which devices are even available in that area (preview option), it is necessary to click "Show markers"; see Figure 7O where the layout of the dashboard card will be displayed; picture 7P.

The system also provides cards with device statuses. Such a tab will display the statuses of all existing devices, unless (optionally) we select a specific zone, filter the devices and display only those located in the area of one of the zones defined in the system as shown in Figure 7Q. The layout of the card on the dashboard is shown in Figure 7R.

Example 8 – Time filters

Time filters are used in various reports to display data only for certain periods of the week, eg weekdays or weekends. In this way, we can analyze the data in a reduced volume and intuitively select the data that interests us.

In order to define or edit time filters, it is necessary to select Configuration - Time filters in the left menu. Time filters can be private or public: public are visible to all users, and private only to the user who created them; see Figure 8A in this regard. To add a new time filter, click the "Add" button. After that, we enter the name and description of the time filter and define whether it is public or private, Figure 8B. We enter periods by clicking on the "Enter at least one item" button. When entering an item, we must select one or more days of the week and the beginning and end of the period on that day, Figure 8C. When entering the start and end time of the period (by clicking on the clock icon), select the hour on the dial first, then the minutes and click "Set" to complete the selection, Figure 8D. After selecting the time, click "Add", Figure 8E.

For each selected day of the week, one period was added as in Figure 8F. We can remove periods or add new ones by clicking "Add". When all periods have been defined, click "Save". The visibility of the time filter can also be changed in the filter table by clicking on the wrench icon next to each of the filters. It is also possible to visually display all defined time filters by clicking on the "Calendar" button; see Figure 8G.

The system designed in this way enables monthly, weekly, and daily display of the list of periods for the selected time period in the calendar; see Figures 8H, 8I, 8J. We use time filters in various reports, for example in graphical analyses, where in addition to other parameters of the report, we can select a time filter and thus display time series only for selected periods of the week, as shown in Figure 8K.

Example 9 – Graphic reports

The system enables the creation of a wide range of graphic reports with the following types of analysis:

- analysis of time series - enables display and comparison of different measurements over time;

- correlation analysis – enables the display of dependence between two measurements; you

- heat map analysis - enables the display of the dependence of the measurement level in a matrix where the vertical axis represents the time within the day, the horizontal axis the date of the year, and the color the intensity.

Graphical reports can contain several different analyses. On the display of the list of reports, the user can:

- search reports;

- create new reports;

- edit the existing report;

- delete reports (unless it was created by another user);

- change the visibility of the report from private to public (visible to all users), and vice versa.

The above options are illustrated in Figure 9A.

When creating a new report, see Figure 9B, it is necessary:

- enter the name of the report;

- define the visibility of the report (visible only for the current user, or for all users); you

- add at least one analysis (time series or correlation report, or heat map).

The time series report, see Figure 9C, consists of:

- a line or column graph showing all selected measurements;

- tables with summary data (for the entire period) for individual measurements; you

- tables with exact amounts of measurements in certain time periods.

The system is designed in such a way that the user can define the reporting period in 2 ways; eg select a past period from the drop-down menu (today, yesterday, current week, etc.) or enter the start and end of the period manually, as shown in Figure 9D.

Data can be grouped into larger or smaller periods in the (above) selected time interval; eg 1/4 hour, day, week, month, quarter, year; as shown in Figure 9E. The report settings also allow you to select a time filter from the drop-down menu, eg display data only on weekend days, only on weekdays and the like, see Figure 9F.

We change or add the measurements we want to display by clicking on "Select item" as shown in Figure 9G. We can choose an arbitrary number of measurements. When selecting items, we can use filtering by type or a simple search, and previously selected measurements can be removed as shown in Figure 9H.

Figure 9I shows an example of a report in which the "Weekend" filter is applied. It can be seen that there are only data in the periods marked as weekends (colored gray). The display of each individual measurement on the graph can be changed from a linear display to a column display and vice versa, as shown in Figure 9J. There are several variants of line graph display: "Line" (standard), "Area" - the area under the line is shaded, and "Spline" - measuring points connected by a smooth line to look like a curve.

“Bar” indicates a bar graph, and the menu for selecting a line graph is shown in Figure 9K. The change of display from column to line is shown in Figure 9L.

Example 10 – Correlation analysis

When analyzing the correlation, it is necessary to select two measurements whose values in a certain time period are displayed as points on the graph, see Figure 10A. In the example from Figure 10A, one measurement, x-axis, shows energy consumption, and the other shows the volume of filled bottles on the y-axis. Each point represents an (x,y) pair at some time. The program logic for the correlation display allows the selection of only two items because time is an implicit item. The layout of the menu for one production process can be seen in Figure 10B.

If we want more measurement data (a denser display), it is necessary to change the "Grouped by" setting to a smaller period such as a day or an hour; compare image 10C and 10D and the difference in the density of dots is visible.

Example 11 – Reports of incoming data

The incoming data report provides two variants of data display. The first is the so-called "Custom Interval" where you need to select the start and end of the period as shown in Figure 11A. By selecting an item as shown in Figure 11B, we can select one or more measurements. The selection result is shown in Figure 11C.

When we clicked "Add", the selected measurements will be displayed in the list and it is necessary to click "Apply", figure 11D, in order to display the data. The data is displayed on the right side of the settings selection form as shown in Figure 11E.

Another variant is the "Comparison by day" display. By selecting from the calendar, we add one or more dates to the list. Then it is necessary to select the beginning and end of the period in the day we are observing or leave the initial (default) settings and thus observe the whole day as in Figure 11F. We select the measurement items similarly to the previous display. After selecting the settings, clicking the "Apply" button as shown in Figure 11G, the data is displayed on the right side as illustrated in Figure 11H. It is convenient to note that the data for the same measurement but for different days are displayed in a different color on the graph, such as the day in Figure 11H.

Example 12 – Report of limit values

The limit values report compares data for the entire day (on selected dates) with the night period, which is considered a period of relative inactivity in the production or consumption cycle. This functionality in the improved version of the execution can be upgraded with other options; for example, that comparisons are made with the night, default (default) day or arbitrary period; given the fact that periods of relative inactivity may be different from the normal circadian rhythms of humans.

In one of the implementation examples, it is necessary to select the desired date from the calendar and the measurements that we want to observe in the manner shown in Figures 12A and 12B. In the table, see how it is illustrated in figure 12C, the data for the selected date, as well as a couple of previous days and a couple of days following the selected date are displayed. The first part of the table refers to the whole day, and the second to the night period. The data on the minimum, maximum and average in the night period are also shown as a percentage in relation to the whole day in order to get a picture of whether the night consumption is realistic or not, and to notice possible excessive consumption in periods when they should be reduced to a minimum because there is no production or consumption cycle.

Example 13 – Device status report

The device status report is designed to show an insight into the correct/irregular arrival of data from certain devices, i.e. delay or suspension of data flow. For each device in the table, a colored indicator is displayed on the status of the device and the age of the data that was last received into the system, and a map with the locations plotted for each device is displayed, as shown in Figure 13A.

The data can be filtered using the drop-down menus by device model as shown in Figure 13B, data age - see Figure 13C, and by device zone, see Figure 13D. It is also possible to select (filter) devices according to their status, as shown in Figure 13E. We can review the status of individual measurements on the device by clicking on the icon next to each device and by clicking on the location drawn on the map, or edit the device settings; see Figure 13F. So the system is designed to be very flexible regarding the status of the device.

If we have selected the overview by measurements, instead of the table with the status of the device, a table is opened that shows individual measurements and their status. You can return to the device status display by clicking the button in the upper right corner. Details about the measurement can be displayed by clicking on the name of the measurement in the list; see in this sense figures 13G and 13H.

Example 14 - Meter status report

The meter status report, see Figure 14A, allows us to compare the data that arrived in the system at the beginning and at the end of the time period in the system, with the calculation of the smallest time periods that the system automatically calculates to enable more detailed behavior analysis. The terms used have the following meanings:

- "Difference": represents the difference in value between the first and last received data for the selected month;

- "Estimated difference for the month": represents the difference in the assessment of the balance at the beginning of the month and at the end of the month, which may differ from the previous item if the data did not arrive exactly from midnight of the first day to midnight of the last day;

- "Calculated value" represents the sum of values automatically calculated by the system for every quarter of an hour in the selected month; and

- The "Error" columns represent the difference between the previous two columns in absolute amount and percentage. This difference should ideally be zero.

Clicking on the name of a measurement in the table opens a new window detailing the selected measurement as shown in Figure 14B, with the data shown in Figure 14C.

Example 15 - Management of periodic sending of reports (SCHEDULING)

The system enables the periodic sending of reports by e-mail in such a way that the user selects the users to receive the report and the time of sending for a certain type of report. On the device status report, click the "Schedule report sending" button; as shown in Figure 15A. From the drop-down menu, select one or more users who will receive the report, see Figure 15B. In addition to the name and surname of each user, we also see the email address to which the report will be sent; Figure 15C. It is also necessary to select the sending time and click "Set" as shown in Figure 15D.

The user can change the default name of the e-mail subject that the system will send and enter a new desired name. If the user wants to send the report immediately, he can do so by clicking the "Send report to me" or "Send report to users" button. The report will be sent with the settings shown in the pop-up window, although the report is not yet scheduled for automatic sending, see the situation in Figure 15E. Device status report is scheduled and sent with selected filters. Filters are selected from drop-down menus and it is possible to select multiple filters at the same time. The collapsed filters are forwarded to the pop-up window and saved together with the configuration for periodically sending reports by e-mail, Figure 15F. When sending a report, the system displays data according to the selected filters.

Example 16 - Setting company and device location

For each company, it is possible to set the location by using the map and placing a marker (eng. pin) at the desired location or by entering the exact address of the company. For input details, see "Setting device location" below, as the procedure is the same for all, see the option marked with an arrow in Figure 16A.

For each device, when editing the same or entering a new device, it is possible to set the location where the device is located. By clicking on the icon in the "Measurement location" section, as shown in Figure 16B, a map opens, where the location of the device should be selected.

The exact address can be entered in the "Search location" field, or a marker can be placed by clicking on any place on the map, see example in Figure 16C. Once selected, the location and address will be displayed at the bottom and must be confirmed by clicking on the check mark icon at the bottom, as shown in Figure 16D.

Example 17 – Location reports

The location report provides an overview of all locations in the system, along with the measurement properties defined for that location, Figures 17A and 17B. Using this report, it is possible to edit the location by clicking the button in the table and changing the address/location (similarly to the device as described earlier) or the measurement property, as indicated by the arrow in Figure 17C.

By clicking on the "Location Details" icon for one of the locations, the unit of measure and consumption for the last 30 days will be displayed, as well as the average consumption as illustrated in Figure 17D.

Example 18 - Zones

The system allows users to define zones over a multitude of measuring devices, so that they can group measurements at a location and view them as a separate unit. A series of input, output and control measurements can be defined for each zone and their values can be compared.

When viewing data about a zone, it is possible to observe data about inputs to the zone (measurements marked with Input/Input), about exits from the zone (measurements marked with Output/Output) or the net difference between Input and Output. The net difference can be used as an indicator of potential losses in the zone if the zone is completely covered by sensors that measure all inputs and outputs.

For each zone, it is also necessary to define a "Measurement property"; eg "Water consumption" "Electricity consumption" or similar.

In the same geographical area, there can be several zones with different measurement properties. It is possible to create several zones that overlap, for example a zone that represents the whole city and a smaller zone by districts or by DMA (District Metering Area) zones. There are no restrictions on the size of the zones, but the functionality of the zone depends on the geographical location of the device or measurement. If the zone does not delimit a particular measurement, it will not be able to use it in its definition, see Figure 18A. In the list of measurements, it is possible to select a quick display of details about the zone and a graphic display of the data, see Figure 18B. When editing a zone, the user can change the name, description, measurement property, zone boundaries on the map, or define output, input and control measurements as shown in Figure 18C.

When creating a new zone, we enter the zone name, description and measurement property. To define the boundaries of the zone, it is necessary to click on the map icon, see the arrow mark in Figure 18D. In order to display the devices with their locations on the map, you should select the "Show all markers" check box, as indicated by the arrow in Figure 18E. Then the display of the device on the map looks like in Figure 18F.

Using the mouse, it is possible to mark edge points that delimit the desired area on the map. Delimitation of the zone is completed by clicking on the starting point when the selected area of the zone changes color, see the situation in Figure 18G. The final confirmation of the selected zone is saved with the button Confirm zone.

All measurements from devices that were displayed on the map within the zone boundaries will be automatically listed in the "Output measurements" list, see Figure 18H. From the "Output measurements" group, each of the measurements can be transferred to the "Input measurements" or "Control measurements" group using the drag-and-drop option, Figure 18I. Any of the listed measurement groups can be empty. When all the desired measurement groups are defined, the user can click "Save" and start using zones for various reports, tabs on the dashboard, and the like, as shown in Figure 18J.

Zones can also be used in graphical analyses. Thus, the system enables a graphical analysis to be made for each zone, in which the defined sets of measurements are viewed as separate groups. Output, Input and Control measurements for each zone in the system are generated automatically and represent the sum of measurements in the Output, Input and Control groups. An example of such a graphical analysis can be found in Figure 18K.

In this way, the measurement data of the mentioned groups can be compared for different time periods, similarly to all other types of data; measurements, standardized measurements, virtual measurements, etc.

Example 19 – Predictive models and analytics

Predictive models and analytics represent the added value of this system. A dataset of 700 different sensor measurements was collected from three large factories where the system was tested. Depending on the factory, for each of the implemented sensors, the system had measurements going back several years of behavioral monitoring; at least a time series of two years. Measurements are readings of sensor values every 15 minutes, and a data set in the form of time-value was made from them. Data/sensors related to energy sources, i.e. their consumption, are particularly interesting. Some of them are: electricity, water, gas; and of course other sensors can be included according to the client's wishes.

All data are visualized in the form of graphs at the level of 15 minutes, 1 hour, 1 day, 1 week and 1 month. An example of such a time series is shown in Figure 19A for power consumption.

Refinement and classification of data is an important factor of prediction accuracy. In the application, we show the user data, i.e. sensor measurements over a period of time. The data may contain sensor anomalies/errors in the system, and we want to correct them before displaying the data to the user. It is important to note that we do not want to correct anomalies due to real events. The technical problem to be solved is that for a given signal one wants to predict sensor readings in the next X days (eg X=30 days). For this purpose, Python libraries such as Prophet, ARIMA or similar advanced systems based on machine learning can be used within the subject system.

Anomaly detection is an important input filter. For a given sensor and measurements, we want to detect different anomalies. Anomalies can occur due to a sensor error (ellipse marked with a dashed line) or due to a sensor that does not work or does not send data for a period of time (ellipse marked with a solid line), see Figure 19B. Anomalies can also arise due to unexpected behavior in the factory itself, and we are particularly interested in such events. A real example that happened is that a pipe burst in the factory, which can be detected as a constant increase in water consumption in the data, and not immediately detected as "expenditure" of water in the factory itself. The intention of the system architecture is to inform the user through the application that something suspicious is happening with the water sensor, and everything is for further verification in situ.

From all that was said before, it is interesting to look at the forecast of energy consumption in the next X days. If for a given energy we want to predict its consumption over a period of time, most often it is a month in order to estimate "overhead costs", the same can be done using the previously mentioned Prophet® library. An example of using Prophet® on the system in question is shown in more detail below. Prophet® is a Facebook® open-source library for predicting the behavior of time series. The advantage is that it does not require parameter adjustment for each sensor, but the system itself "learns" from behavior. An example of prediction is shown on the example of lighting in the plant in Figure 19C, where the predictive part refers to the time period from 02/03/2018 onwards.

As part of the research according to the subject invention, a method for the approximate reconstruction of missing data was developed. This method uses the so-called "Exponential smoothing", see e.g. https://en.wikipedia.org/wiki/Exponential_smoothing, respecting the day and time of the week which allows improves the quality of the approximation. This method can also be used to easily predict future consumption.

The purpose of this method is to reconstruct the data in cases where the data is stable and there is a long series of historical data on the basis of which the reconstruction can be made. The use of this method is done automatically within the system by calling the "forecast" method, which receives a list of readings, a granularity label (quarter hour, hour, day) and the number of data to be evaluated. An example of a prediction based on historical data is shown in Figure 19D; the first part (actual measurements) represents an interval of stable data, then there is an occasional dropout of the sensor before complete failure. This mixed set is labeled mix in Figure 19D. After the date of 8.12, it is about virtual measurement - reconstruction of data based on the history of the measurement site.

As part of the program modules, an algorithm was additionally developed for data processing, cleaning and normalization within a time window of 15 minutes. Interpolation works by taking the 2 closest values to the moment for which we want the data. In case there is no data that is close in time, interpolation is done, but the data is marked with a special flag. The algorithm works by simultaneously detecting interruptions (whether there is no data or the counter being reset) and error detection. The main idea of the built-in algorithm was that the counters count in ascending order, so the algorithm tries to create a non-falling sequence as long as possible based on the input data. This uses a modified version of the longest increasing subsequence algorithm https://en.wikipedia.org/wiki/Longest_increasing_subsequence). If the algorithm detects a negative value between two data, it is considered that either an error or a break has occurred. Likewise, a special system for processing input data was developed. The system functions so that during processing it retrieves all the data that the system received since the last processing and starts processing.

In the event that the newly received data contains data that is older than the last processed data, the algorithm retrieves all the data that was created between those two data and deletes them. After that, further data processing begins, which uses linear interpolation to find the data as close as possible to the reporting moment (at 15 min). After that, the system generates reporting data for all timestamps between the last processing and the current processing.

1.7 Industrial Applicability

The subject invention is industrially applicable in the broadest sense. It reveals a new and inventive IoT platform for the collection, processing and monitoring, analysis, control and optimization of measured data and for the management and monitoring of devices.

1.8 References

10. and measuring devices

20.j gateway components

30 broker messages

40 ERP system

50, 50', 50“ firewall

60 frontend components

70 backend component

80 authentication server

90 databases

100,000 clients

i, j, k integers greater than zero

Claims (6)

1. The operation procedure of the IoT (Internet of Things) platform for collecting, processing and monitoring, analyzing, controlling and optimizing measured data and for managing and monitoring a multitude of measuring devices (10), which consists of one or more gateway components (20), a broker message (30), optionally one or more ERP systems (40), firewalls (50, 50', 50"), frontend component (60), backend component (70), authentication server (80) and database server (90) ) organized in the industrial part of the network (I) and the system located in the cloud (C) with software support for the components listed above; and at least one client (100) accessing the cloud system (C); where: - the industrial part of the network (I) contains one or more gateway components (20.1, 20.2, ...) connected by a firewall (50) to the part of the system located in the cloud (C); where a plurality of measuring devices (10.1, 10.2, ...), each of which is connected to only one gateway component (20.1, 20.2, ...), converts the analog measured quantity into a digital one and forwards it to the gateway component (20.n) to which it is assigned and which communicates with a message broker (30) located in a part of the cloud system (C); - the cloud system (C) monitors the industrial part of the network (I) using the backend server (70), which is the main component of it, which executes all the business logic and where the backend server (70) is connected via the message broker (30) and the firewall ( 50') located on the side of the cloud system (C) for the firewall (50) placed in front of said gateway components (20.k) of the industrial part of the network (I); - the cloud system (C) also has a frontend server (60) whose program support serves to display data from the backend server (70) to which it is connected, where one or more clients of the system (100.k) access the data through the firewall (50" ) according to the mentioned frontend server (60) with the support of the authentication server (80) responsible for the authorization of the user of the user (100.k) according to the backend server (70); - the database server (90) carries out storage and preservation of all system data generated in time; from data of measuring devices (10.i), access time, system health, permission to access measured values up to the time of data access by each of the clients (100.j); indicated that: - each client (100) accesses the cloud system (C) through a unified interface with restrictions in the display mode and data manipulation previously recorded on the authentication server (80) with restrictions on the available measured data defined on the backend server (70), whereby the cloud system (C) adapts the graphical display of the system state to the client's physical device (100); - the cloud system (C) signals and informs the client (100) in case of deviation of one or more measuring devices (10), under the supervision of the mentioned client (100), from previously defined parameters; you - the cloud system (C) enables integration of multiple measuring devices (10.i) into structural units, computationally, based on data from two or more measuring devices (10.i). 2. The operating procedure of the IoT (Internet of Things) platform for the collection, processing and monitoring, analysis, control and optimization of measured data and for the management and supervision of a multitude of measuring devices according to claim 1, indicated by the fact that the structural units are related to the territory, to the type of process monitored, or a combination of process and territory; and optionally with a defined hierarchical structure. 3. The operation procedure of the IoT (Internet of Things) platform for the collection, processing and monitoring, analysis, control and optimization of measured data and for the management and supervision of a multitude of measuring devices according to claim 2, indicated that each hierarchical structure is changeable so that the client ( 100) can independently change and adapt to its own analytics if it has the permission of the authentication server (80) for such action in the system. 4. The operation procedure of the IoT (Internet of Things) platform for the collection, processing and monitoring, analysis, control and optimization of measured data and for the management and supervision of a multitude of measuring devices according to any of the previous requirements, indicated by the fact that it enables the review and monitoring of the correlation of two variables in time; where each of the mentioned variables is selected from a set consisting of: a measuring device, a structural unit of measuring devices or only a part of a structural unit. 5. The operation procedure of the IoT (Internet of Things) platform for the collection, processing and monitoring, analysis, control and optimization of measured data and for the management and supervision of a multitude of measuring devices according to any of the previous requirements, indicated by the fact that the structural units of the spatial zone are previously selected on the graphical interface by the client (100). 6. The operation procedure of the IoT (Internet of Things) platform for collecting, processing and monitoring, analyzing, controlling and optimizing measured data and for managing and monitoring a multitude of measuring devices according to any of the previous requirements, characterized by the fact that the cloud system (C) signals and informs the client (100) about the state of the system at pre-defined time intervals with automated reports sent according to pre-selected communication channels.