A running engine system and its application

Abstract

The present application relates to the field of Internet of Things technology, and specifically to a running engine system and its application. If there are problems with existing terminals, support from manufacturers is required; if new functions are required, new terminals can only be purchased from manufacturers, which is inefficient and costly. The present application provides a running engine system, including a development language running environment and a subsystem group. The subsystem group includes a message bus subsystem, an APP running subsystem, an APP management subsystem, and an APP operation and maintenance subsystem. The APP running subsystem is connected to the message bus subsystem, the APP management subsystem is connected to the message bus subsystem, and the APP operation and maintenance subsystem is connected to the message bus subsystem; the running engine system is arranged on an edge IoT proxy device, and the IoT APP runs on the running engine system, and the running engine system is connected to a cloud system. The engine is installed on an edge IoT proxy device and is adapted to various types of edge IoT proxy devices through cross-compilation.

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Things, and in particular to a running engine system and its application. Background Art

[0002] With the advent of the Internet of Things era, people's demand for the number and capabilities of IoT devices is gradually increasing. In other industries such as electricity, common IoT scenarios such as monitoring, remote control, and computing are all implemented using the architecture of edge IoT agent + end-side sensor devices. The edge IoT agent is usually a small computer with basic computing and transmission functions. It is connected to various end-side sensor devices and switch devices for monitoring and remote control. Most end-side devices are finished products that interact using general protocols such as modbus. The edge IoT agent plays a connecting role. To the bottom, it needs to be able to parse and send messages of multiple protocols to communicate with the end side. To the top, it needs to be able to communicate with the upper-level cloud system, upload data collected by the end-side device, or receive instructions issued by the cloud, or complete edge computing tasks.

[0003] In the era of the Internet of Things, the data on the edge has exploded. The traditional edge collection + cloud computing method has posed new challenges to the data center and computing power of the cloud. In order to cope with the impact of massive data, edge computing is a common approach. The edge IoT agent solves the collected data on the spot through IoT APP calculation, and only reports the result data required by the business, which greatly reduces the pressure on cloud applications. It also gives full play to the computing power of the edge IoT agent. Taking monitoring and alarm services as an example, the edge IoT agent regularly performs monitoring tasks and calculates according to specific algorithms. If everything is normal, it will not report or only report a small amount of data according to business requirements. When an exception occurs, the exception result and detailed information will be reported. The pressure on communication between cloud computing and cloud edge is reduced.

[0004] Existing monitoring, remote control, and computing functions are usually implemented using IoT apps running in edge IoT agents. Currently, most edge IoT agents use embedded arm and arm64 architecture computers from many manufacturers. For technical and commercial reasons, IoT apps from different manufacturers are usually not reusable, and most are pre-installed at the factory, with no subsequent modification or update capabilities.

[0005] If problems arise with existing terminals, support is needed from the manufacturer; if new features are needed, users can only purchase new terminals from the manufacturer, which is inefficient and costly for users. Summary of the invention

[0006] The purpose of this application is to provide a running engine system that can adapt to various types of IoT terminals through cross-compilation, so as to realize the universal deployment of IoT APP across manufacturers and types of IoT terminals.

[0007] 1. The technical solution adopted in the present application is: the present application provides a running engine system, including a development language running environment and a subsystem group, the subsystem group includes a message bus subsystem, an APP running subsystem, an APP management subsystem and an APP operation and maintenance subsystem, the APP running subsystem is connected to the message bus subsystem, the APP management subsystem is connected to the message bus subsystem, and the APP operation and maintenance subsystem is connected to the message bus subsystem; the development language running environment is used to provide code interpretation and thread management for the subsystem group; the running engine system is arranged on an edge IoT agent device, the IoT APP runs on the running engine system, and the running engine system is connected to a cloud system.

[0008] Another implementation mode provided by the present application is: the development language is Node.js language, C language, Java, Python or Go language.

[0009] Another implementation scheme provided by the present application is that the message bus subsystem adopts the MQTT communication protocol, the DDS communication protocol, the AMQP communication protocol, the XMPP communication protocol, the JMS communication protocol, the REST communication protocol or the CoAP communication protocol.

[0010] Another implementation method provided by the present application is: the APP running subsystem includes an APP splicing module, an APP control module and an APP execution module; the APP splicing module is used to combine the APPs into executable js codes; the APP control module is used to realize the start, pause, resume and stop of the Internet of Things APP; the APP execution module is used to encapsulate multiple APPs in different asynchronous functions to realize high-performance operation of the Internet of Things APP.

[0011] Another implementation method provided by the present application is: the APP management subsystem includes an APP version management module, an APP registration management module and an APP resource management module; the APP version management module is used to implement the management of different versions of the same APP when they are issued; the APP registration management module is used to register APP information in the APP resource center; the APP resource management module is used for APP resource management, responsible for storing the node files and process files of the APP running in this engine, and sending the node and process files of the newly issued or updated APP to the APP splicing module.

[0012] Another implementation method provided by the present application is: the APP operation and maintenance subsystem includes a message feedback module, a log management module and an operation and maintenance management module; the message feedback module is used to feedback the operation results of the APP to the cloud system; the log management module is used to generate and manage engine logs; the operation and maintenance management module is used to control the running status of the running APP, and receive instructions issued by the cloud system by subscribing to specific topics on the message bus subsystem.

[0013] Another implementation method provided by the present application is: the engine log includes engine operation information and APP operation information.

[0014] Another implementation method provided by the present application is: the instruction content includes an instruction type and an APP ID; the instruction type includes start, stop, pause and resume.

[0015] The present application also provides an application based on the runtime engine system, which applies the runtime engine system to a cloud orchestration APP.

[0016] Another implementation manner provided by the present application is: the cloud orchestration APP includes components, processes and APP description information; the components include component logic code and component description information.

[0017] The beneficial effect of the present application is that the running engine system proposed in the present application is suitable for the IoT APP running engine of the edge IoT agent.

[0018] The operating engine system proposed in this application is installed on an edge IoT proxy device and adapted to various edge IoT proxy devices through cross-compilation.

[0019] The running engine system proposed in this application is that the IoT APP runs on the running engine, is unaware of the differences in the underlying hardware, and realizes the universal deployment of the IoT APP; the engine can accept the IoT APP sent from the cloud to realize the remote installation of the IoT APP; the engine can return the running data of the IoT APP to the cloud, and the user can send and specify in the cloud to control the start, stop, update, and deletion of the IoT APP, thereby realizing the cloud-based operation and maintenance of the IoT APP. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a schematic diagram of the operating engine system principle of this application;

[0021] Figure 2 This is a schematic diagram of the operation and maintenance management module in the APP operation and maintenance subsystem of this application;

[0022] Figure 3 This is a flow chart of the APP management subsystem-APP version management module of this application;

[0023] Figure 4 This is a flowchart of the APP management subsystem-APP registration management module of this application;

[0024] Figure 5 This is a schematic diagram of the basic storage structure of the APP resource management module of this application;

[0025] Figure 6 This is a schematic diagram of the new APP operation process of the APP resource management module of this application;

[0026] Figure 7 This is a schematic diagram of the principle flow of stopping the APP runtime in the cloud of this application;

[0027] Figure 8 This is a schematic diagram of the engine startup workflow of this application;

[0028] Fig. 9 This is a schematic diagram of the workflow when the cloud system of this application issues the APP;

[0029] Fig.10 A flowchart of the process of issuing instructions to the cloud system of this application;

[0030] Fig.11 This is a schematic diagram of the cloud orchestration APP principle of this application. DETAILED DESCRIPTION

[0031] Hereinafter, the specific embodiments of the present application will be described in detail with reference to the accompanying drawings. According to these detailed descriptions, those skilled in the art can clearly understand the present application and can implement the present application. Without violating the principles of the present application, the features in the various embodiments can be combined to obtain new implementations, or certain features in certain embodiments can be replaced to obtain other preferred implementations.

[0032] See also Figures 1 to 11 The present application provides a running engine system, including a development language running environment 1 and a subsystem group, the subsystem group including a message bus subsystem 2, an APP running subsystem 3, an APP management subsystem 4 and an APP operation and maintenance subsystem 5, the APP running subsystem 3 is connected to the message bus subsystem 2, the APP management subsystem 4 is connected to the message bus subsystem 3, and the APP operation and maintenance subsystem 5 is connected to the message bus subsystem 2; the development language running environment 1 is used to provide code interpretation and thread management for the subsystem group, and the running environment is different according to the development language selected by the subsystem, and the two correspond one to one.

[0033] The running engine system is set on the edge IoT agent device, the IoT APP runs on the running engine system, and the running engine system is connected to the cloud system 6.

[0034] Furthermore, the development language is Node.js language, C language, Java, Python or Go language.

[0035] The engine proposed in this application is developed using Node.js and includes five major parts: Node.js runtime, message bus, APP running function, APP management function, and APP operation and maintenance function.

[0036] Furthermore, the message bus subsystem adopts MQTT communication protocol, DDS communication protocol, AMQP communication protocol, XMPP communication protocol, JMS communication protocol, REST communication protocol or CoAP communication protocol.

[0037] The message bus subsystem 2 used in the running engine system of the present application is used for communication between the engine modules. Since the engine is applied to the field of Internet of Things, the MQTT protocol is adopted. The MQTT communication protocol is a "publish-subscribe" mode. An MQTT broker is established as a channel. After connecting to the broker, the publisher can publish a message consisting of "topic + message". The subscriber can connect to the broker, subscribe to the target topic, and obtain the required message. Each module has the functions of MQTT publishing and MQTT subscription.

[0038] Furthermore, the APP running subsystem 3 includes an APP splicing module 7, an APP control module 8 and an APP execution module 9; the APP splicing module 7 is used to combine the APPs into executable js codes; the APP control module 8 is used to realize the start, pause, resume and stop of the Internet of Things APP; the APP execution module 9 is used to encapsulate multiple APPs in different asynchronous functions to realize high-performance operation of the Internet of Things APP.

[0039] Since IoT applications have the characteristics of simple functions and repeated cycles, the APP control module 8 uses a timer to achieve control, and the timer ID is the same as the APP ID. Once the APP starts to execute, the timer automatically starts and repeatedly executes the APP. The APP control module 8 only controls the APP in the engine and does not manage it. Except for the automatic execution of the start command at the first startup, the start, pause, resume, and stop commands in other cases come from the operation and maintenance management module 15 in the APP operation and maintenance subsystem 5 and the APP resource management module 12 in the APP management subsystem 4.

[0040] The running engine proposed in this application is implemented based on Node.js. Since Node.js has high performance of single-threaded asynchronous, the engine can run multiple IoT apps at the same time. Multiple IoT apps do not need to start multiple processes. The APP execution module 9 is used to encapsulate multiple apps in different asynchronous functions to achieve high-performance operation of IoT apps. The APP execution module 9 includes anonymous function creation, function asynchronous execution, and callback result viewing.

[0041] After the APP splicing module 7 realizes the transformation from the cloud orchestration APP to the Node.js executable js file, the js file will be handed over to the APP execution module. The APP execution module 9 will first create an anonymous function to wrap the executable code in the js file to achieve isolation between APPs, and create a callback function to define the status result reported to the engine after the APP is executed or the execution is abnormal. After that, multiple anonymous functions are executed asynchronously, and the callback result is enabled to view, and the callback results of each APP are polled to view the callback results of each APP, and the operation status of each APP is monitored in real time.

[0042] Furthermore, the APP management subsystem 4 includes an APP version management module 10, an APP registration management module 11 and an APP resource management module 12; the APP version management module 10 is used to implement the management of different versions of the same APP when they are issued, and obtains the APP and the version information of the APP by subscribing to a specific topic on the message bus, and makes corresponding judgments. When the cloud system 6 issues an APP, the APP version management module 10 will first process it. If it is the first time for a new APP to be issued, or a new version of an existing APP is issued, it will be handed over to the APP registration management module 11 for processing. If there is an older or the same version of the existing APP, it will not be processed.

[0043] The APP registration management module 11 is used to register APP information in the APP resource center; when the cloud system 6 issues an APP, the APP version management module 10 controls the version information. If it is the first time for a new APP to be issued, or a new version of an existing APP to be issued, the APP version management module 10 will send information to the module, and the APP registration management module 11 will complete the APP registration function. The APP registration management module 11 maintains the "Engine Running APP" table. The registration process is: if it is the first time for a new APP to be issued, a new record will be created in the Engine Running APP table, with the content of APPID, version number, and update time; if it is a new version of an existing APP, the existing record will be searched according to the APPID, and the version number and update time of the corresponding APP in the update table will be updated.

[0044] The APP resource management module 12 is used for APP resource management, responsible for storing the node files and process files of the APP running in this engine, and sending the node and process files of the newly issued or updated APP to the APP splicing module. When the APP registration management module 11 completes the APP registration, it will send information to the APP resource management module 12, and the information content is: APPID, operation type, APP resources. APPID is the APPID issued by the cloud system, the operation type is divided into new creation and update, and the APP resources are the APP node and process files issued by the cloud system 6.

[0045] The node files and flow files of the APP are classified and saved in the APP resource management module 12. The flow files are named according to the APPID and stored in the flow folder. The node files are named according to the node ID + node version number and stored in the nodes folder.

[0046] When the operation type is new creation, the APP resource management module 12 will send the APP resources to the APP splicing module 7, which will complete the APP splicing and subsequent operation work, and save the process and nodes of the APP at the same time.

[0047] When the operation type is update, the APP resource management module 12 will send a stop command to the APP control module 8, and send APP resources to the APP splicing module 7 at the same time to complete the splicing and operation of the new version of the APP.

[0048] When the operation and maintenance control module 15 receives the APP stop command issued by the cloud system 6, it will send the APPID to the APP registration management module 11, which will delete the registration information of the corresponding APP, send the APPID to the APP resource management, delete the process information of the corresponding APP, and retain the node file. The APPID will be sent to the APP control module 8, and the APP control module 8 will delete the timing trigger of the corresponding APP.

[0049] Furthermore, the APP operation and maintenance subsystem 5 includes a message feedback module 13, a log management module 14 and an operation and maintenance management module 15; the message feedback module 13 is used to feedback the operation results of the APP to the cloud system; the log management module 14 is used to generate and manage engine logs. The size limit of a single log file is 50MB. If it exceeds the limit, a new file will be created and the new log file name will be named according to the time.

[0050] The operation and maintenance management module 15 is used to control the running status of the running APP, and receives instructions issued by the cloud system 6 by subscribing to a specific topic on the message bus subsystem.

[0051] After the APP isolation module encapsulates the APP as an anonymous function and executes it asynchronously, the callback information generated by each APP will be published through the message bus. The message return module 13 can subscribe to the APP callback information on the message bus and publish the message through the message bus in combination with the APP description information. The cloud system can subscribe to the corresponding topic to view the messages of different APPs.

[0052] The instruction content includes two parts: instruction type and APPID. The instruction type can be divided into four categories: start, stop, pause, and resume. After receiving the message, the operation and maintenance management module 15 sends a message to the APP control module 8 through the message bus subsystem 2, and the APP control module 8 executes the corresponding function. The APP control module 8 has a built-in timing trigger for each APP. When a pause signal is received, the trigger will be suspended. When a stop signal is received, the trigger will be deleted, and the corresponding APP information will be deleted in the APP resource management module 12.

[0053] The present application also provides an application based on the runtime engine system, which applies the runtime engine system to a cloud orchestration APP. The engine proposed in this application is a runtime engine suitable for a cloud orchestration APP. A cloud orchestration APP refers to an IoT APP developed in the cloud using visual, low-code development tools. A cloud orchestration APP consists of components and processes. A component is an encapsulation of data and methods, and is the smallest component unit of a cloud-orchestrated APP. A process is a file that describes the connection relationship between components. This application uses Node.js as the interpreter for the IoT APP, the components are implemented using js files, and the processes are implemented using json files. The engine is deployed as a software on the edge IoT proxy device.

[0054] The IoT APP run by this application is an IoT APP developed using cloud orchestration technology. Cloud orchestration technology splits the IoT APP into two major parts: "components + processes". Components are code encapsulations that implement specific business functions, and processes are description files that describe the connection relationship between components. Messages are passed between components and processed accordingly to ultimately complete business functions. A typical cloud orchestration APP is shown in the figure below. The cloud orchestration APP contains components, processes, and APP description information.

[0055] A component should contain at least two contents: component logic code and component description information. For components applicable to this application, the component logic code is saved in the js file, and the component description information is saved in the package.json file.

[0056] The component logic code usually contains three parts: message reception, message processing, and message publishing. According to their position in the process, components can be divided into three categories: initial component, intermediate component, and final component. The initial component is responsible for creating messages and sending them to the next component after processing; the intermediate component receives messages from the previous component and sends them to the next component after processing; after receiving and processing the message, the final component does not need to publish it. It can choose to write the results to the log or send them to the message bus subsystem 2 according to business needs.

[0057] The package.json file contains component information, which usually includes five parts: component name, component version number, component ID, component logic file name, and developer related information. The component ID is the unique identifier of the component, which consists of numbers and letters. The component logic file name is the file name where the main entry function of the component logic code is located. The component version number is used for APP resource management functions.

[0058] The process is a json file that describes the connection relationship between the components in the APP. In this file, each component is uniquely identified by an ID, and each component used in the APP is described as a record in the process. The record content usually includes: component ID, previous component ID in the process, and next component ID in the process. If the same component is used multiple times in the APP, the component ID will be followed by a serial number to distinguish it, and the serial number and ID are separated by special symbols.

[0059] The APP splicing module will unpack the contents of each component according to the cloud orchestration APP parsing specification, and splice them into independent executable js files that can run in Node.js according to the description in the process file.

[0060] The runtime engine proposed in this application is adapted to various types of IoT terminals through cross-compilation. Cross-compilation refers to generating executable files on the target platform through a cross-compiler on the host machine. The host machine can use a personal PC with a Linux system, or other x86 architecture devices, to configure the cross-compiler, and use a cross-compiler, such as gcc, on the host machine to compile and generate a runtime engine that can run on the edge IoT proxy device. The IoT APP runs on the runtime engine. Since the engine has been adapted through cross-compilation, the IoT APP is unaware of the differences in the underlying hardware, thereby realizing the universal deployment of IoT APPs across manufacturers and types of IoT terminals.

[0061] The running engine proposed in this application runs on the IoT terminal and communicates with the cloud system 6. Through cloud-edge collaboration and using the downlink channel, it realizes the remote deployment and upgrade of the IoT APP; and uses the uplink channel to realize the cloud operation and maintenance of the IoT APP on the Yuan IoT agent.

[0062] The running engine proposed in this application is suitable for cloud orchestration APP and has the ability to interpret and run cloud orchestration APP.

[0063] The components and processes in the APP resources are managed separately. When updating the APP, if only the process is updated but not the components, the cloud only needs to send the new version of the process file; at the same time, the component library is universal for multiple APPs. If different APPs use the same components, there is no need to send the existing components. This greatly reduces the size of the update package and improves the update success rate.

[0064] By using the runtime engine as the adaptation layer between hardware (edge ​​IoT agent) and software (IoT APP), the software is unaware of the differences in hardware, achieving software and hardware decoupling. IoT APPs can be universally deployed on different types of edge IoT agents. The same IoT APP can be reused multiple times, reducing the cost of repeated development.

[0065] Through the cloud-edge collaboration achieved by the running engine, the IoT APP in the edge IoT agent can be upgraded remotely. When users have new needs, they can directly update the APP in the terminal, reducing the cost of replacing terminals when upgrading functions.

[0066] No need for on-site updates, all updates and distribution operations on the IoT APP can be completed in the cloud, which is convenient and fast, improving user experience. It reduces production losses caused by users having to send back equipment and reduces the cost of personnel going to the site.

[0067] 4. As the smallest unit for implementing IoT APPs, commonly used components will be repeatedly used in multiple APPs. The running engine and component library in this solution are shared by multiple APPs, and commonly used components do not need to be sent repeatedly, which reduces the size of the update package and improves the update success rate.

[0068] like Figure 2 As shown, when the cloud sends an instruction, the message is sent through the message bus subsystem 2, the operation and maintenance management module 15 subscribes to the message, receives the message and parses it, and if it is a command to stop a certain APP, the command is forwarded to the APP registration management module 11, and the APP registration management module 11 performs subsequent operations. Figure 7 ; Other non-stop commands (start, pause) will be sent to the APP control module 8, and the APP control module 8 will control the APP.

[0069] like Figure 3As shown, when an APP is sent down from the cloud, it is first processed by the APP version management module 10. After parsing the APP description message, it checks the APP resource library. If the APP does not exist, it is determined to be a newly issued APP, stored in the library and starts running. If the APP exists, it needs to be checked according to the version number. If the version number of the issued APP is less than or equal to the APP version in the library, it will not run; if the version number is greater than the existing APP, it is determined to be an update to the existing APP, stored in the library and started running, and the process ends.

[0070] like Figure 4 As shown, the APP registration management module 11 is responsible for registering the APP information in the APP resource center. When the cloud system sends the APP, the APP version management module 10 controls the version information. If it is the first time for a new APP to be sent, or a new version of an existing APP is sent, the APP version management module 10 will send information to the APP registration management module 11, and the APP registration management module 11 will complete the APP registration function. The APP registration management module 11 maintains the "Engine Running APP" table. The registration process is: if it is the first time for a new APP to be sent, a new record will be created in the Engine Running APP table, with the content being APPID, version number, and update time; if it is a new version of an existing APP, the existing record will be searched based on the APPID, and the version number and update time of the corresponding APP in the update table will be updated. Then the APP resources will be sent to the APP resource management module 12, and the process ends. See the subsequent process. Figure 6 .

[0071] like Figure 5 As shown, APP resources are abstracted into two parts, nodes and processes, in the APP resource management module 12. Each APP contains a process and the nodes it uses. Different APP processes are different, and each APP is only allowed to run one version at the same time, so the process can be bound to the APPID as a unique identifier. Since nodes can be reused, different APPs may use the same node or different versions of the same node, so in the node library, the unique identifier of each node is the node ID + node version number. Nodes and processes are stored separately. If a new APP is issued, but the nodes it uses are already in the library, the nodes do not need to be saved repeatedly, saving storage space.

[0072] like Figure 6 As shown, when the APP registration management module 11 receives the APP and sends it to the APP resource management module 12, the APP resource management module 12 executes different commands according to the different registration module operation types. If it is an update, a stop command is first sent to the APP control module 8 to stop the running old version of the APP. Then the APP resources are saved and sent to the APP splicing module 7 to assemble the APP. If it is a new creation, there is no need to stop, and the resources are saved and the APP is spliced ​​directly.

[0073] like Figure 7 As shown, when the operation and maintenance control module 15 receives the APP stop command sent from the cloud, it will send the APPID to the APP registration management module 11. The APP registration management module 11 will delete the registration information of the corresponding APP and send the APPID to the APP resource management module 12 to delete the process information of the corresponding APP. The node file needs to be checked. If there is no APP that references the node, the node file will be deleted. If there is, it will still be retained. Subsequently, the APPID will be sent to the APP control module 8, and the APP control module 8 will delete the timing trigger of the corresponding APP. Thus, the operation of the APP is stopped.

[0074] like Figure 8 As shown, after the engine is started, it will first query the running APP information in the APP registration management module 11, obtain the APPID of the running APP, and then request APP resources from the APP resource management module 12, that is, process + node. After that, the APP resources are sent to the APP splicing module 7 to assemble the APP, and the timing trigger is set for each APP through the APP control module 8. Finally, the APP is run in the running environment through the APP execution module 9. Then the startup phase ends.

[0075] like Fig. 9 As shown, when an APP is sent from the cloud, it will first pass through the APP version management module 10 to check whether the APP is an existing APP. If so, it will check again whether the APP is a new version. If not, the process will end directly. When the APP is a new version of an existing APP, or a brand new APP, an update or new creation command will be sent to the APP registration management module respectively, and then the resources will be saved through the APP resource management module 12. If it is an update operation, the old version of the APP will be stopped, and the new one does not need to be stopped, and the APP will be directly spliced. Through the APP control module 8, a timing trigger is set to start the APP.

[0076] like Fig.10 As shown, when the cloud sends an instruction, the instruction will be received and analyzed by the operation and maintenance management module 15. If it is a stop instruction, it is necessary to eliminate its operation information through the APP registration management module 11, and delete the content of the APP resource management module 12, and then go to the APP control module 8 to stop the running APP; if it is a non-stop command, it will be directly sent to the APP control module 8, and then through the APP execution module 9 to control the start and stop of the APP.

[0077] like Fig.11As shown in the figure, the cloud orchestration APP consists of processes and components. The component is a code package that executes specific business logic, and the process is a description file that describes the connection relationship between components. Each component basically contains three parts: message reception, message processing, and message publishing. The component receives the message sent by the previous component, performs logical processing, and finally sends it to the next node. Components can be divided into three categories: initial components, intermediate components, and end components. The initial component does not need to receive messages and can be generated by itself. Generally, there is only one initial component in a process; the intermediate component is responsible for receiving the message sent by the previous component, processing it and sending it to the next component; the end component only receives and processes the message, and no longer passes it back, generally for data reporting functions.

[0078] Although the present application is described above with reference to specific embodiments, it should be understood by those skilled in the art that many modifications may be made to the configurations and details disclosed in the present application within the principles and scope disclosed in the present application. The scope of protection of the present application is determined by the appended claims, and the claims are intended to cover all modifications included in the equivalent literal meaning or scope of the technical features in the claims.

Claims

1. A running engine system, characterized in that: It includes a development language operating environment and a subsystem group, wherein the subsystem group includes a message bus subsystem, an APP operating subsystem, an APP management subsystem and an APP operation and maintenance subsystem, wherein the APP operating subsystem is connected to the message bus subsystem, the APP management subsystem is connected to the message bus subsystem, and the APP operation and maintenance subsystem is connected to the message bus subsystem; The development language runtime environment is used to provide code interpretation and thread management for the subsystem group; The runtime engine system is set on the edge IoT proxy device and is adapted to various types of edge IoT proxy devices through cross-compilation; the IoT APP runs on the runtime engine system, has no perception of the differences in the underlying hardware, and realizes the universal deployment of the IoT APP; the runtime engine system is connected to the cloud system; the APP running subsystem includes an APP splicing module, an APP control module and an APP execution module; The APP splicing module is used to combine the APP into an executable js code; The APP control module is used to start, pause, resume and stop the IoT APP; The APP execution module is used to encapsulate multiple APPs in different asynchronous functions to achieve high-performance operation of IoT APPs; the APP management subsystem includes an APP version management module, an APP registration management module and an APP resource management module; The APP version management module is used to manage the issuance of different versions of the same APP; The APP registration management module is used to register APP information in the APP resource center; The APP resource management module is used for APP resource management, responsible for storing the node files and process files of the APP running in this engine, and sending the node and process files of the newly issued or updated APP to the APP splicing module; the APP operation and maintenance subsystem includes a message feedback module, a log management module and an operation and maintenance management module; The message feedback module is used to return the running results of the APP to the cloud system; The log management module is used to generate and manage engine logs; The operation and maintenance management module is used to control the running status of the running APP, and receives instructions issued by the cloud system by subscribing to specific topics on the message bus subsystem.

2. The operating engine system according to claim 1, characterized in that: The development language is Node.js, C, Java, Python or Go.

3. The operating engine system according to claim 1, characterized in that: The message bus subsystem adopts the MQTT communication protocol, the DDS communication protocol, the AMQP communication protocol, the XMPP communication protocol, the JMS communication protocol, the REST communication protocol or the CoAP communication protocol.

4. The operating engine system according to claim 1, characterized in that: The engine log includes engine operation information and APP operation information.

5. The operating engine system according to claim 1, characterized in that: The instruction content includes instruction type and APPID; the instruction type includes start, stop, pause and resume.

6. An application based on the operation engine system according to any one of claims 1 to 5, characterized in that: The runtime engine system is applied to the cloud orchestration APP.

7. The operating engine system according to claim 6, characterized in that: The cloud orchestration APP includes components, processes and APP description information; the components include component logic code and component description information.

Images