This article is shared by Liancheng from Amoy IOT front end team
The background,
Industrial Internet is a hot topic in the industrial field in recent years. It is not only included in the national strategic plan, but also necessary for the transformation of industrial manufacturing. Factory digitization is the value of the future industry, industrial Internet is the form of digital transformation and the only way. Digital scheme is the key part of the factory is cloud of various types of factories on the standardization of offline data access, the factory data contains goods, raw materials, inventory, production planning, production scheduling, order, the market, such as all kinds of data information, how these disturbing data in a standard format of low cost, quick access to the cloud platform, is the most critical problem facing now, This paper will introduce a software and hardware integration scheme of data device gateway equipped with dynamic script engine to help factory data to the cloud quickly and at low cost.
Second, the pain points
As described above, our goal is to connect the complex and chaotic factory data of each factory to the cloud data platform in a standardized format by means of the device gateway. We encountered the following three problems.
### problem status
1) Various data source interfaces: Some large factories have their own ERP systems. Our equipment CAN be connected with them through TCP/HTTP and other network protocols, while many small factories that rely on manual management have only a few machine tools. We CAN only connect with machine tools through Modbus/UART/CAN and other hardware buses to collect production data.
2) The proliferation of private agreements among manufacturers: some factories with information management ability manage the production process through private agreements in THE ERP system, but most of the time we cannot directly obtain detailed production data from ERP, so we need to extract effective information from private agreements. But we are faced with the current situation is that each factory proprietary agreement is multifarious, there is no uniform law.
3) lack of data format standards: in the process of data collection in the factory, we will face different levels of data, data from the top of the ERP classification to the underlying machine output bytes of source data, we need to these tumultuous data filter cleaning, catalogued, encapsulated into a standard data format to our access to the data platform.
Given the status quo, developers face the following three challenges.
# # #
1) High development cost: IOT device end environment, repeated compilation and burning time-consuming and laborious; Single process application, hardware drive and data protocol conversion logic coupling, encounter a data source development, there is a lot of repetitive work.
2) High personnel requirements: developers need to understand industry and manufacturer protocols and data access; At the code level, it is necessary to understand the application of full-link embedded development from bottom to top and be familiar with all kinds of network and hardware protocols.
3) High operation and maintenance costs: online operation and maintenance is unavailable, and the IOT equipment needs to be on business trip to the factory site if there is an anomaly; Each data source corresponds to a device firmware, and the management workload is large. Firmware upgrade and batch operation are completed manually, which is time-consuming and laborious.
Iii. Technical scheme
## Dynamic solution
As shown in the above, this paper puts forward a set of with equipment dynamic scripting engine is given priority to, covers the front end and back end link equipment console soft hard integration solutions, all of them, and its main application management, online debugging operations, and other functions, condition monitoring, the clouds, the core business logic is written in a scripting language, reduce the cost of equipment the development and operations.
### Core content
1) Communication link construction: Based on cloud RPC, communication link construction, and the capability of the device side is revealed to the cloud page.
2) Abstract device hardware capability: such as peripheral configuration, open/close, data read/write, and according to a certain format of JSON protocol.
3) Write business logic in scripting language: write algorithm/business logic and output results based on abstracted hardware capabilities and JSON protocol.
4) Application containerization: deliver script applications from cloud pages, manage application life cycle in the whole process, and manage various applications just like mobile apps.
### Scheme advantage
1) Reduce the development cost: according to the equipment capacity, packaging mainstream hardware bus ability, C/C++ main program solidified reuse, no need to repeatedly modify; The conversion of factory-source data is completed by script application. One type of access to a script has less code, good dynamic, and no need to compile and burn repeatedly. The cloud delivers management script application. Hardware transparency, low development threshold, hardware and business development separation, understand the script can complete protocol adaptation development.
2) Reduce operation and maintenance costs: the front page of equipment capability is revealed to solve the difficult problem of non-screen device interaction; Cloud console, support remote operation and maintenance, no need to travel on site; Supports one-click application upgrade and batch management.
### page display
The above figure shows the basic information of the device in Aliyun IOT Pass. We can see the online status, firmware version, activation time, IP address and so on.
The figure above shows the cloud control window on the device side. The cloud control part has three functions. The first one is rPC-shell, which can be regarded as a simple terminal window. The second function is that the cloud pushes MQTT messages to the device, so that the cloud mock messages can be combined with the device. The third function is remote SSH. Ordinary SSH can only access LAN devices without public IP addresses. After remote SSH is enabled, we can log in to the device in any network environment through SSH links protected by keys and enable Web-shell remote SSH, which facilitates remote operation and maintenance of the device.
The picture above shows the device end application management, contains scripts to add issued, application code switch, log application to view, update, check, and other functions, each application information is stored in the equipment side, in the form of a card to show on the web end and provide the corresponding UI interaction, script applications continue to run on the device end, factory side original data to clean filtered into the standard form of data, Report to the cloud.
C/C++ main program encapsulates all kinds of hardware bus and is based on the Local MQTT to the JSON protocol, script application can configure the hardware bus through the local MQTT, and then the script can get the data read by the hardware bus from the local MQTT, after cleaning and protocol conversion, Output to the gateway for forwarding to the cloud.
The figure above shows the status monitoring of the device side. At present, the network, process, network card, memory and external storage information of the device side are transparent to the Web side, so that the students of development and operation can check the current running status of the device at any time.
Fourth, technical thinking
Let’s look at the picture above. Except the peripherals and business logic of the colored part change according to the scene, other gray modules are neutral without business attributes, so most of the capabilities of this dynamic architecture are reusable. The following are my thoughts and practice on this architecture scheme.
Thinking and Practice:
Thought 1: Can other non-industrial IOT scenarios reuse this architecture?
Yes, full scene coverage! The previous project of cloud Computing Conference applied this architecture, and the core algorithm business logic code was only more than 100 lines. The above two examples are very typical IOT scenario-based applications, which are the scenarios of persistent algorithm detection and persistent feedback control respectively.
Thought 2: Are script engines limited?
In theory, any lightweight script that supports MQTT should work, such as Node.js, Python, Lua, PHP, etc.
Thought 3: What is the biggest difficulty of this scheme?
Device-side hardware capability abstraction and application lifecycle management.
Thought 4: Is there a disadvantage?
Interprocess communication delays and system resource consumption. At present, on NXP’s IMX6UL single-core chip platform, a node application consumes 10-20m (2%-4%) of memory, 3-4% of CPU, and 1-2ms of interprocess communication delay.
Thought 5: Can the technical architecture be exported?
Yes, according to the different development resources of the business side, the output can be in the form of device side, device side + server side SDK, device side + server side SDK+ front end.
5. Future prospects
Device friendly interaction
Android makes it easy for devices with screens to interact with each other, while non-screen devices use cloud console pages instead of screens to interact with each other anytime, anywhere.
Development process lightweight
IOT development needs to reduce the development cost and entry threshold, we need to minimize the construction environment, compilation and packaging, serial port debugging, firmware upgrade and other time-consuming and labor-intensive operations, so that more novices start IOT development at low cost, out of the box.
Export and promotion?
At present, we mainly support standardized access business of factory data, and support other offline business according to demand. In the future, it is worth discussing whether to build a small and beautiful hardware similar to Tmall Genie and Raspberry PI, equipped with dynamic architecture engine, and promoted in the form of community, so that more people can experience the fun of IOT development.
