Source | elephant article | knife

0, the words written in the front

To be honest, I have little experience in the Internet of Things industry.

Do software born of me, before also learned some SCM knowledge, as well as radio frequency, ZigBee such as wireless transmission protocol, because that period of time “smart home” fire, young and ignorant I also follow crazy, and then no and then……

Thinking back to their previous enthusiasm for technology, or worthy of affirmation, but that kind of almost blind pursuit, a bit too much.

In short, new technologies or concepts learned need to be put into practice in time. Long shelving will lead to nothing at last. The feeling of having nothing at all in the end is also a blow to my enthusiasm.

1. Background

Now, with the continuous expansion of the company’s business, a batch of equipment needs to be connected to our platform, so I try to design the equipment gateway system architecture of our company.

At present, all connected wireless devices, devices and carriers can move at any time, using common SIM card traffic, so there is no fixed IP address. As for the core functions of device gateway 1.0, it is also simple and can be divided into three parts:

① Device installation and binding.

(2) Real-time reporting of equipment data

③ Equipment operation and maintenance

Figure 1 Device gateway core functions

2. Four-layer structure

Let’s look at device gateways from another perspective: hierarchies.

I combed through the entire business process and tracked the entire data flow, so it was easy to come up with the following four-tier structure:

Figure 2 Device gateway four-layer structure

The whole hierarchy is composed of data layer, control layer, application layer and performance layer from bottom to top. This hierarchy has also become the guiding ideology of my later system architecture design.

Now a brief introduction to each level:

  • The data layer. At the bottom, the data source of the whole system, is obviously a very basic level.

  • Control layer. This is a key level connecting the preceding and the following, the most important function is the analysis of instructions, as well as the sending and receiving of instructions.

  • The application layer. It can also be called the business layer, which is closely related to the business logic of the system, and the implementation of some business will be played here. On the performance layer, and then through the control layer on the device for instruction sending and receiving, on the access is the control layer, can obtain equipment related data submitted to the performance layer.

  • The presentation layer. It can also be called interaction layer, which is the entry point of human-computer interaction and data visualization. It is not hard to see that this level is directly dealing with people, so it needs to be humanized while meeting business needs.

Through the above introduction and combined with the hierarchy diagram, it is not difficult to draw a conclusion: the data layer and the control layer are business-related, which can be collectively referred to as “protocol layer”, while the application layer and the performance layer are business-related, which can be collectively referred to as “system layer”. The whole hierarchy is independent and connected to each other to achieve the purpose of weak coupling.

3. Architecture Evolution (Level-1)

It was also a painful process to create the entire architecture, lest there were any inconsiderate places that would lead to repeated potholes. I am also very grateful to the industry insiders who provided me with help and advice during this process. Under their guidance, I got more inspiration.

As for the so-called IoT architecture, it is not fully followed. The whole business scenario doesn’t look like a very standard Internet of Things, so you don’t set yourself too high a bar, just design an architecture that works.

First, from a high point of view, the architecture looks like this:

Figure 3 Device gateway system architecture (Level-1)

As shown in the figure, there are four key roles in the device gateway.

  • Devices and Device groups are the most basic roles and belong to the data layer. Considering the possibility of fine management of devices in the future, devices will be grouped according to certain rules (such as region and organization). This part of the design is not very obvious in the early stage.

  • The Center Controller corresponds to the control layer. The role of the main work are data collection, equipment directive transceiver, etc., it is important to note that the inside of the access to the system may be more than one equipment manufacturers, equipment type also is varied, message protocol are also different, so the control platform should be designed to be “is not sensitive to the device type”, in order to improve control platform compatibility, scalability, and availability.

  • Biz Processor, corresponding to the application layer (business layer). This role focuses on the business requirements of the system, including equipment operation and maintenance monitoring, data analysis, persistence, log analysis, of course, which is also built on the basis of the central control platform.

  • Device Management System, corresponding to the presentation layer. This role is directed to the end user and is an operational human-computer interaction platform that can control the entire data chain through the business processor. Because it is the highest level of the architecture, there is a lot of room for imagination through effective integration of the underlying data.

The above is the level-1 of the device gateway architecture, and then we will further analyze the whole architecture and enter Level-2.

4. Architecture Evolution (Level-2)

In this part, we delve into the inner parts of the four characters and get a peek into their structure.

1) Equipment and equipment group. Here we will introduce a concept called “sub-devices”, that is, a device object can be attached to several devices, we call them “sub-devices”. Of course, a device may have no children, depending on the situation.

For example: take a door as a device, then the combination lock, lock tongue, infrared probe can be child devices; The probe for seismic monitoring, for example, is an independent device with no sub-devices.

Figure 4 “sub-device” concept

The purpose of this design is to be able to more refined access to the equipment for control, into controllable single sub-equipment, back to control the entire large equipment. In addition, for all the devices of different sizes in the platform, they do not communicate with each other directly, but deal with the central control platform directly.

2) Central control platform. I position this role as a kind of middleware. The following is the component diagram of the central control platform:

Figure 5 component diagram of central control platform

The whole central control platform is composed of eight components, the following is a simple introduction.

  • Connector. This component is the data transmission channel between the control layer and the data layer, and maintains the data connection between the central control platform and each device. The data transmission connection is based on TCP/IP protocol.

  • The REST API. As the hub of protocol layer and system layer, the central control platform provides connectors for the lower layer and RESTful interfaces for the upper layer. Because the device gateway will use the microservices architecture style, REST APIS are used, leaving aside other remote invocation methods.

  • Message Queue service. It is mainly to solve the application coupling, asynchronous message, traffic cutting and other problems, and finally achieve high performance, high availability, scalable and final consistency architecture, which is conducive to the realization of quasi-real-time communication between the protocol layer and the system layer.

  • Protocol Parser. This component is easy to understand because the protocol specifications are different for different source devices and different device vendors, and need to be translated through a protocol parsing engine and formalized within the system. This part of the work is completely transparent to the upper system and only requires data interaction according to the specifications within the system. Therefore, protocol parsing is bi-directional, from the inside out, and from the outside in.

  • Command Executor. In this component an up-to-date “instruction set” is maintained, each instruction having a specific function, depending on the protocol parsing engine, corresponding to different functions on different devices.

  • Data Collector. As the name suggests, the main task of this component is to collect all the data from the device and record it with the logging service. Data collectors can be roughly divided into two categories: real-time and non-real-time collectors that respond to different timeliness according to business requirements.

  • Logger Service. There are two types of logs recorded in this section: data logs and device logs. The format of log storage is beyond the scope of this article, and the two types of data are described here. – Data log records the data flowing through the control layer, which is divided into three types: (1) Source data, also known as “bare data”, this part of the data without any processing, straight out of each device; (2) Structured data, this part of the data is closest to the business data, the source data for rough processing formed; ③ Business data: structured data is further integrated and processed according to the business requirements of the system. – Device logs record data related to devices on the access platform. They are divided into two types: (1) Device status, which records device status flow data. (2) Instruction sending and receiving, recording is the central control platform for equipment instruction sending and receiving data.

  • Management Toolkit. This part can be considered as the value-added services of the central control platform, with the lowest priority, but there is also a lot of room for imagination. I plan to design it as a service that can respond to Terminal commands, such as getting the current number of connections, what is the maximum number of connections, instruction set configuration, sending instructions to devices and so on.

3) Business processor, which is a role related to business, can be designed according to actual business requirements. When I design the business processor, I focus on the device and expand on the other capabilities. The following is a topology diagram of a business processor, but the specific business requirements will not be described.

Figure 6 Service processor topology

4) Equipment Management System. In this part, I think there should be two “visualizations” : data visualization and equipment visualization. “Data visualization” is easy to understand, which is the integration and graphical representation of data. Of course, the source of data can be real-time or offline processing. There are mature solutions in this industry. Another is “device visualization”, which is mainly to give ordinary users a friendly operation experience and visualize the device. Clicking different buttons can trigger its corresponding functions. Of course, for expert users, in-station Terminal can also be provided to directly use commands to interact with the device.

Figure 3 Two “visualizations” of the device management system

5, summary

The whole paper expounds the four-layer structure of the device gateway, and analyzes the system architecture of the device gateway in two layers. The technical details are not covered in the whole article, because this is the technical architecture level content, will be covered in a new article.

Hope can be helpful to you!

THANKS!

-END-