Task
We at the Synergy Team design and manufacture industrial controllers. They are designed for resource accounting, energy management and other applications, which are commonly referred to as the Internet of Things (IoT). Often, our customers don't just need controllers. They need a complete solution that includes a control system.
And this system should be close to optimal: fast, light and reliable. But, according to the well-known anecdote, it is impossible to simultaneously fulfill all these requirements. We need to look for a balance depending on the task, which we tried to do.
In this post, we limited ourselves to the class of tasks when IoT controllers are directly connected to the control system ( Directly-connected IoT ). So, our task is to develop a management system that should:
- transfer data from sensors connected to controllers,
- send events (for example, about temperature rise, door opening, loss of communication, etc.),
- transmit control commands to actuators,
If the system consists of a large number of objects and / or performs critical tasks, it must additionally:
- constantly monitor the presence of communication with objects,
- collect statistics on your work,
- update controller settings and software (upon request);
- be protected from unauthorized access. For state and large private companies, the system must also comply with the legislation on working with critical information infrastructure (CII). In particular, the requirements of 187-FZ, FSB, FSTEC, orders of the Ministry of Telecom and Mass Communications, etc.
Management without a dedicated server
For several objects, the problem is simply solved with control over the GSM network by means of SMS commands or calls. This approach was popular in the early 2010s, and its pros and cons are described, for example, here . For most serious systems, this approach is losing its relevance today.
Slightly more complicated is the “manual” control of the controllers via dedicated IP via the WEB or the command line (CLI). Controllers must be permanently connected to the network, have static "white" or "gray" IP addresses. Alternatively, you can use dynamic IP with binding to static domain names using DynDNS technology or similar . This works well if there are few objects and there are no special requirements for reliability.
Disadvantages:
- , WEB () ;
- IP ;
- , NAT;
- IP . , GSM APN ;
- , «»;
- ().
For quick demonstrations, control over several objects, it is enough to use control by IP, SMS or phone calls.
Here we did not consider the situation when the dispatcher is running on the same computer and the control system is installed, since we consider it a degenerate case of the next item.
Dedicated server management
In the remaining cases, you need a server with a dedicated IP, through which controllers, dispatchers and third-party systems will connect.
If the controllers transmit data only in the direction of the server, for example, water meters or the simplest navigation devices (trackers), a unidirectional connection is sufficient. In this case, the controllers only need to know the server IP.
In our task, two-way data exchange is required to update the controller software and transmit commands. To organize such an exchange, you must:
- periodic reading of settings or commands from the server at the initiative of the controller (acceptable if you do not need a quick response to commands), or
- using static IP or domain names on the controllers so that the server can "reach" them on its own, or
- , . , MQTT, EGTS ( ). IP. , .
When it comes to a control system based on a proven and reliable solution, SCADA is the first thing to remember. And this is fully justified when it comes to the automation of production or a large energy facility. In a word, when the system contains a large number of sensors and actuators of various types. Such systems require the development of mnemonic diagrams and algorithms for equipment interaction that are unique for each object, which is perfectly thought out in SCADA.
If you need to monitor and / or manage objects of the same type (as in the proposed task), then using SCADA can make the solution too "heavy" due to the complexity of configuration, laboriousness of adding standard objects and increased requirements for server performance. It is best to use one of the specialized box systems on the market that is most suitable for the task. For instance:
- monitoring and management system for network equipment - Network management system (SNMP, TR-069, CLI);
- automated metering system for heat, electricity, gas, water. For brevity - ASKUE;
- navigation tracking system of mobile objects with onboard systems control;
- climate control system (ventilation, air conditioning and heating) - HVAC;
- smart home / office / building system;
- : , () , ;
- - , ..
These systems often overlap each other's functionality. For example, on the basis of ASKUE it is possible to implement control of outdoor lighting, and on the basis of the "Smart House" to control the climate and access. The expansion of the functionality of "living" systems is ongoing. New APIs are emerging for integrating boxed products into customer solutions, as well as support for custom functions in boxed software. A huge advantage of boxed products is the fact that they can be bought and put on your server, having received an alienated solution that works in a closed customer circuit.
If you have plans to sell your own system on the free market, you need to understand that a competitor may grow out of today's boxed software supplier tomorrow. In addition, the use of box systems carries such additional risks as:
- increase in the price of licenses,
- weak control over the system (there is no source code, even if there is, it is extremely difficult to maintain),
- many systems can only be used as a cloud service, which may be unacceptable for large and / or government projects.
Development based on IoT platforms
If using boxed software is not possible, it would be a good idea to develop on one of the popular IoT platforms . Such platforms contain universal modules required in any IoT system for:
- registration and deletion of IoT devices,
- secure authentication of IoT devices and maintaining communication with them,
- working with data (databases optimized for different tasks),
- registration of users and management of access rights,
- formation of analytics based on the collected data,
- generating notifications for users (SMS, E-Mail, push messages, ...),
- storing the latest data read from IoT devices,
- performing various actions on events,
- data visualization, etc.
The architecture of a system on an IoT platform is practically independent of its size. All tasks related to load balancing, eliminating database "brakes" and "heavy" functions are undertaken by the platform. In addition, the server side of the application is quickly assembled from "cubes" - microservices. Both the time to market and the cost of the solution, which directly depends on the payment of the programmers' work, are reduced.
A system on an IoT platform can be developed in a minimum of time. Its architecture will not change much with increasing size.
Pros of developing on a cloud-based IoT platform:
- . AWS . . .
- , , , MQTT- – . , .
- IoT . ( ) ( IoT ).
- .
- the primary development task can be outsourced. In the future, the solution will be able to support not only the developers of the original system, as is usually the case. After all, IoT platforms have powerful technical support, are well documented, and the number of developers who can work with them is steadily growing.
Disadvantages:
- components of IoT platforms operate only at the facilities of their owners, create a completely alienable system that will work in the customer's data center, possibly in rare cases;
- the cost of using an IoT platform for large projects may be higher than the cost of renting virtual machines in a data center;
- migration from one IoT platform to another involves changing a decent amount of code. Although there is now a trend towards API standardization;
- By no means all IoT platforms are deployed in data centers within Russia, which makes it impossible to use them in the interests of government customers.
Completely own development
If the shortcomings of previous solutions are critical, you need to develop your own solution. And no matter how good the plan is, the first versions of the system will be crooked.
Own solutions are often implemented on the basis of such open-source systems as ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia glial. For small projects, they can be too "heavy" due to:
- long development time and corresponding financial costs. Usually counts are in person-years;
- as the number of objects grows, bottlenecks will arise in the form of slow databases, collectors, report generators, etc., for the resolution of which it will be necessary to change the architecture and supplement it with balancers and duplicate resources;
- costs of ongoing administration and technical support.
At the same time:
Own development is justified either for government orders, or projects with ambitious plans and large budgets, or when independence and security are critical.
If you need a quick demonstration ( MVP ), then it can be done on an IoT platform or boxed software, adopting time-tested approaches, while developing your own large solution in parallel.
Conclusion
Based on the analysis of different systems, we propose the following control system selection algorithm.
For demonstrations and small IoT projects for several objects, you can use direct control over IP, SMS or through GSM calls. Otherwise, a top-level system is required. The use of SCADA is justified in industrial automation and at large energy facilities. For resource accounting, network equipment management, tracking, security, "smart home", etc. it is convenient to use a boxed solution of the required specialization. Developing systems on IoT platforms is more difficult, but gives more perspective and flexibility. Solutions on foreign IoT platforms are seriously limited in scale and application areas in Russia. The most difficult thing is completely own development. And it is justified only for government orders and the most ambitious projects.At the same time, for quick demonstrations and copying best practices, it will be useful, in parallel with your own development, to make a draft design on the IoT platform.
Finally, we want to share a small forecast:
- in cloud IoT platforms, it is worth waiting for the appearance of pre-configured templates for "Smart Home", AMR, NMS, ACS, etc. This will further simplify the use of IoT platforms and attract an even larger audience.
- traditional developers of SCADA and other boxed solutions will offer more tools for external developers that have proven themselves in IoT platforms. Closed box solutions are unlikely to withstand market competition.
- domestic IoT platforms for public and large private customers will develop even more actively.
- The APIs of different IoT platforms will become more similar over time. Because of this, the transition from one IoT platform to another will be simplified.
In the next, more technical post, we will talk about our project for monitoring communication systems on the AWS platform and GIC controllers .
Be sure to write in the comments if we missed something important. One of the goals of our blog is to get constructive feedback.