DTU module management system, management method and deployment method

Abstract

The invention belongs to the technical field of DTUs, and particularly relates to a DTU module management system, management method and deployment method, and the system comprises a monitoring program module and a remote uploading and updating module. And process isolation and authority management of the DTU module improvement system are realized based on the formalized verification microkernel seL4, and unauthorized access and hostile attack are prevented. Rapid expansion and integration of functions are realized through a modular architecture, user-defined modules and protocols are supported, and modularization and dynamic loading of DTU functions are realized, so that different industrial protocols or functional modules (such as Modbus, OPC UA, MQTT and the like) can be added in a plug-in expansion mode, and the whole system does not need to be recompiled.

Description

Technical Field

[0001] The present application belongs to the field of DTU technology, and specifically relates to a DTU module management system, management method and deployment method. Background Art

[0002] At present, DTU (Data Transfer Unit) modules are widely used in industrial automation, intelligent transportation, environmental monitoring and other fields. Existing DTU systems are usually based on traditional operating system architectures and have basic functions such as data acquisition, monitoring and remote control. These systems generally use a single hardware platform to implement specific functions through preset firmware and applications. However, with the continuous advancement of technology and the diversification of market demand, existing DTU systems face challenges in the following aspects: Modular design: Many existing DTU systems lack flexibility in architectural design and cannot quickly adapt to the integration of new functions or protocols. Script management: The management of user-defined scripts often relies on complex compilation and deployment processes, which is not conducive to rapid iteration and adjustment. Security: Traditional operating systems are insufficient in process isolation and permission control, which can easily cause system vulnerabilities and security risks. Summary of the invention

[0003] The present invention aims to solve the deficiencies of the existing DTU (Data Transfer Unit) module in terms of security, flexibility, modular design, script management and resource scheduling. The technical solution is:

[0004] A DTU module management system, including a monitoring program module and a remote upload and update module;

[0005] Monitoring program module: provides a running environment for user scripts, manages user script tasks, isolates user script tasks securely, and handles errors in user scripts;

[0006] Remote upload and update module: user script upload, user script update and user script debugging. Different functions in DTU are designed as independent modules, each module is responsible for specific functions independently, and the seL4 isolation mechanism is used to ensure that modules communicate through designated interfaces. Functional modules can be used as independent libraries to support subsequent dynamic loading and replacement; modules interact through a unified interface, and a public interface is defined for each module. New modules can be integrated by simply implementing the corresponding interface.

[0007] Preferably, the monitoring program module includes:

[0008] Provides a running environment for user scripts: processes user scripts through the Lua parser, creates independent Lua service components, and integrates with the seL4 microkernel; provides a safe and efficient script execution environment, and allows users to write scripts using Chinese variable names; communicates with other services through IPC to access external resources;

[0009] Manage user script tasks: Manage and schedule multiple user script tasks, use a fixed-priority time slice round-robin scheduling algorithm to ensure concurrent running and efficient scheduling of script tasks, prioritize key tasks, and run each script task as an independent thread;

[0010] Secure isolation of user script tasks: Utilize seL4's process isolation and permission management mechanism to ensure that each user script runs in an independent memory space and restrict its access rights; through capability mechanisms and IPC, restrict the interaction between scripts and external resources;

[0011] Error handling of user scripts: Capture and handle various errors in script execution, and feedback error information through IPC; avoid resource leakage through timely isolation and resource release, and try to restart the failed task when necessary.

[0012] Preferably, the remote upload and update module includes:

[0013] Upload of user scripts: implement Wi-Fi driver, configure lwip network protocol stack, allow users to connect to DTU module through mobile devices and upload script files, establish TCP server process based on seL4 to receive script upload requests, pass received script files to script parser thread through seL4 IPC mechanism, use TLS to ensure data transmission security, and verify data integrity and source through hash check and digital signature; provide remote script upload capability, so that users can easily update scripts and temporarily store uploaded script files for subsequent parsing and execution;

[0014] User script update: After receiving a new script update package, integrity verification is performed and new script tasks are dynamically deployed. New user-mode threads are created and capability resources are allocated to ensure the safe execution of new scripts. Dynamic deployment of new script tasks is supported to achieve real-time script updates. Users are allowed to send uninstall requests through the wireless interface and release resources occupied by old scripts to ensure that old scripts are safely uninstalled before new scripts are deployed to avoid resource leakage.

[0015] Debugging of user scripts: Implement remote debugging interface, users can view script running status; establish debugging communication channel through Wi-Fi or network cable, accept multiple client connections based on TCP protocol; use Lua's built-in debug library to obtain script runtime information, and provide debugging command processing; support user remote debugging, real-time script modification, view variables and execution status, and allow users to set breakpoints and single-step execution.

[0016] Preferably, cross-module communication uses the IPC or message passing mechanism of seL4, and each module performs secure message passing through the efficient IPC mechanism provided by seL4; modules communicate with each other in an event-driven manner, supporting asynchronous processing.

[0017] A DTU module management method, a method for providing a running environment for a user script in a monitoring program module is:

[0018] Process the user script through the script parser, obtain the Lua parser source code, modify the source code, and run the Lua parser based on the seL4 microkernel;

[0019] On seL4, each user-mode task runs as an independent thread, and the Lua parser will also run as an independent thread; create a Lua service component using the cAmkES component model; load the Lua parser into the system and allocate specific memory space and permissions for it;

[0020] Define Lua service component: define a Lua service in the ADL of cAmkES, and interact with other services of the seL4 kernel by using the service program defined by cAmkEs;

[0021] Lua supports UTF-8 encoding by default, and users can directly use Chinese variable names; modify the keyword parsing part of the Lua parser (llex.c), define the Chinese keyword list luaX_tokens_CN, and add Chinese keywords to the lexical analysis of the Lua parser in the luaX_init function;

[0022] The script parser communicates with other services through the IPC mechanism of seL4. During the script execution process, when it needs to access external resources, the parser will package the request into an IPC message and send it to the corresponding service process; start the main loop of the parser, listen for external uploaded script requests, and run the event processing mechanism of the parser in the main loop, waiting for the user to send the script through the network or serial port interface for parsing and execution;

[0023] When a user uploads a script, the parser receives the upload request through the seL4 IPC mechanism and stores the script code in a predefined memory area. The parser then calls the internal load function to load the script code into the parser's runtime environment. If the script contains syntax errors or illegal operations, the parser returns an error message and transmits the error back to the process or device that uploaded the script through IPC.

[0024] The parser starts to execute the loaded script. The script execution process needs to parse the script one by one and execute the corresponding instructions according to the design of the parser.

[0025] Preferably, the method for managing user script tasks in the monitoring program module is:

[0026] Use seL4's IPC mechanism to receive the uploaded script content and pass it to the script parser process; after the script is uploaded, it is stored in the parser's memory for subsequent execution; each script runs as an independent user-mode thread, and uses the seL4 system call to create a thread for running the script task; in each thread, call luaL_newstate() to create a Lua virtual machine, call luaL_loadstring(lua_State*L,const char*s) function to load the user's script task into the Lua virtual machine, and finally call lua_pcall to execute the script task;

[0027] For multiple script tasks, a fixed-priority time slice round-robin scheduling algorithm is used to schedule the execution of script tasks: for critical tasks, a higher priority is set so that low-priority tasks get smaller time slices, while high-priority tasks get larger time slices, ensuring that critical tasks can respond in a timely manner; time slices are allocated to each script task according to priority; the scheduler will schedule each task in turn according to the FPRR algorithm and determine the execution order of tasks based on priority; high-priority tasks will be rotated to low-priority tasks only after they are executed within each time slice.

[0028] Preferably, the error handling steps of the user script are as follows:

[0029] When the user uploads a script, the parser will load the script content into the Lua virtual machine. When the luaL_loadstring() function is used to load the script, if a syntax error is detected in the script, the error will be fed back to the process that uploaded the script through the IPC provided by seL4, and the loading process will be stopped.

[0030] During script execution, the lua_pcall() function is used to execute script tasks. lua_pcall() can capture runtime errors. If a runtime error occurs, the Lua virtual machine returns error information to the process that uploaded the script through IPC and stops executing the task.

[0031] Each script task runs in an independent virtual memory space. If a script attempts to access an unauthorized memory area, the seL4 kernel will trigger a page fault and interrupt the script execution. The system will capture the error and send the error information to the error handling service through IPC. When an illegal memory access error occurs, the system will immediately terminate the script task, release the resources of the task, and prevent the error from propagating to other tasks.

[0032] Each script task can only access a limited set of resources; if the script attempts to access unauthorized resources, a resource access error will be triggered; seL4 captures unauthorized resource access through the capability system, and the system will send an error message through IPC;

[0033] When an error occurs in a script task, the system will immediately isolate the task and terminate its execution. The error will not affect other running script tasks. When the error script task is isolated, the system will release the resources occupied by the task to prevent resource leakage.

[0034] The error handling service determines whether to restart the task based on the severity of the error. If the error is caused by a temporary failure, you can try to restart the task. The error information will be fed back to the user who uploaded the script through IPC.

[0035] Implement a timer. To prevent script tasks from falling into an infinite loop or occupying CPU resources for a long time, the system can set a timeout detection mechanism. If a task does not return for a long time, the scheduler will mark it as a timeout task and terminate the task.

[0036] Preferably, the method for uploading the user script is:

[0037] Implement Wi-Fi driver based on hardware development board, use lwip network protocol stack to configure Wi-Fi function, user connects to DTU module through mobile device application and sends script file; establish a TCP server process based on seL4 to receive script upload request from mobile device; user sends Lua script file through mobile device; server of DTU module receives script file and stores it in memory area of ​​DTU monitoring program module; received script file is passed to script parser thread in DTU monitoring module through seL4 IPC mechanism; after script file is uploaded, it will be temporarily stored in DTU memory to prepare for script parser loading, and separate memory space is allocated for each script task in seL4;

[0038] Use the mbedTLS lightweight TLS library to encrypt the transmitted data; after receiving the script update package, use the hash function to verify the update package; the server will add a verification value to the update package; after receiving the update package, the DTU module calculates the hash value and compares it with the hash value provided by the server to verify whether the data has been tampered with; if a digital signature is used, after receiving the script update package, use the public key to verify the signature to ensure that the source of the data is credible and has not been tampered with.

[0039] Preferably, the debugging steps of the user script are as follows:

[0040] Establish a debugging communication channel through the wireless interface Wi-Fi or network cable connection, establish a connection based on the TCP protocol, establish a server thread to accept multiple client connections, and process debugging requests from different clients through different ports. It is necessary to create an independent debugging connection for each client;

[0041] Lua provides a built-in debug library to obtain the runtime information of the script; users can view and modify the local or global variable values ​​in the Lua script through the debugging interface; debug.getlocal() and debug.setlocal() are used to read and set variable values;

[0042] When the client requests debugging information, the DTU module needs to send the debugging information to the client through the network connection; the client sends a debugging command to the DTU module, and after the system receives the debugging command, it parses the command and performs corresponding operations.

[0043] A deployment method for a DTU module management system includes the following steps:

[0044] The first step is to initialize the hardware. Start the seL4 microkernel on the development board, initialize all communication interfaces, and implement the drivers of these communication interfaces to call the hardware interfaces to ensure that the device can communicate normally with the gateway.

[0045] Step 2: Deploy the seL4 microkernel to the development board and perform necessary security configurations. Modify and transplant the seL4 microkernel's hardware dependency based on the development board to ensure that the operating system can use the development board's hardware resources and provide complete permission management and security isolation.

[0046] Step 3: Users deploy and run their own script tasks on the industrial gateway through the DTU monitoring program module to implement user-defined functions. Users can configure the industrial gateway by writing scripts; user-defined scripts process the data sent by the cloud platform and the data uploaded by the device.

[0047] Compared with the prior art, the present invention has the following beneficial effects:

[0048] The present invention adopts the fixed priority time slice round-robin (FPRR) scheduling algorithm to manage multiple script tasks, ensuring that key tasks can respond in time. Through the priority scheduling mechanism, high priority tasks can be executed first when system resources are limited, ensuring the efficient operation of the system and the real-time performance of tasks.

[0049] The present invention supports the use of Chinese variable names and Chinese keywords to write scripts, and combined with the UTF-8 encoding support of the Lua parser, it greatly reduces the programming threshold and allows users to write and manage scripts more intuitively and quickly.

[0050] The present invention can isolate the faulty script task in time when an error occurs and release the resources occupied by the faulty script task, thereby preventing resource leakage and system crash.

[0051] By integrating Wi-Fi and TCP network protocol stack, users can interact with DTU modules through wireless networks to achieve remote script upload, update and debugging functions. Users can easily upload, update and uninstall script tasks, and support real-time debugging. This function allows users to flexibly adjust and iterate script content without going through complex compilation and deployment processes, significantly reducing development and maintenance costs, while improving system operability and user experience.

[0052] The design of the present invention realizes the modularization and plug-in expansion of DTU functions. Different functions (such as Modbus, OPC UA, MQTT and other protocol support) can be dynamically loaded and integrated in the form of plug-ins without recompiling the system. This modular design improves the flexibility and scalability of the system, allowing users to quickly add or replace functional modules according to actual needs and adapt to diverse application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 This is a schematic diagram of this application. Specific implementation methods

[0054] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0055] A DTU module management system comprises a monitoring program module and a remote uploading and updating module.

[0056] 1. DTU monitoring program module:

[0057] The DTU monitoring program module is implemented based on the seL4 microkernel. The DTU monitoring program module implements multiple functions to ensure the operating environment, security, management efficiency and error handling of user scripts. This module provides an operating environment for user script tasks, allows user-defined text scripts to run in the DTU module, provides network interfaces, I / O operations and other capabilities, and ensures the real-time and reliability of the system.

[0058] 1. Provide a running environment for user scripts, process user scripts through the Lua parser, create independent Lua service components, and integrate with the seL4 microkernel. Provide a safe and efficient script execution environment, and allow users to write scripts using Chinese variable names, lowering the programming threshold and improving programming efficiency. Communicate with other services (such as network and serial port services) through IPC to access external resources. Process scripts uploaded by users, create a user script execution environment and execute user script tasks.

[0059] 2. Manage user script tasks, manage and schedule multiple user script tasks, use the fixed priority time slice round-robin (FPRR) scheduling algorithm to ensure the concurrent operation and efficient scheduling of script tasks, give priority to the execution of key tasks, improve system responsiveness and performance, and each script task runs as an independent thread to facilitate system management and resource allocation.

[0060] 3. Secure isolation of user script tasks. Use seL4's process isolation and permission management mechanism to ensure that each user script runs in an independent memory space and restrict its access rights. Prevent interference between script tasks and unauthorized resource access to ensure system security. Through capability mechanisms and IPC, restrict the interaction between scripts and external resources to increase security protection.

[0061] 4. Error handling of user scripts: Capture and handle various errors in script execution (syntax errors, runtime errors, memory access violations, etc.), and feedback error information through IPC. Ensure system stability and prevent errors from affecting the operation of other script tasks. Avoid resource leakage through timely isolation and resource release, and try to restart faulty tasks when necessary to improve system robustness and user experience.

[0062] 2. Remote upload and update module:

[0063] In order to realize the remote upload and update module of the DTU monitoring program, it can connect to the user's mobile device through the wireless interface Wi-Fi, allowing the user to remotely upload, update or uninstall the script. This module supports script update and management and provides real-time debugging capabilities.

[0064] 1. Upload user scripts, implement Wi-Fi driver, configure lwip network protocol stack, allow users to connect to DTU module through mobile devices and upload script files, establish TCP server process based on seL4 to receive script upload requests, pass received script files to script parser thread through seL4 IPC mechanism, use TLS to ensure data transmission security, and verify data integrity and source through hash check and digital signature. Provide remote script upload capability, so that users can easily update scripts, ensure data security during upload, prevent tampering, and temporarily store uploaded script files for subsequent parsing and execution.

[0065] 2. Update of user scripts. After receiving the new script update package, integrity verification is performed and new script tasks are dynamically deployed. New user-mode threads are created and capability resources are allocated to ensure the safe execution of new scripts. Dynamic deployment of new script tasks is supported to achieve real-time script updates. Users are allowed to send uninstall requests through the wireless interface and release the resources occupied by the old scripts to ensure that the old scripts are safely uninstalled before the new scripts are deployed to avoid resource leakage.

[0066] 3. Debugging of user scripts, realizing remote debugging interface, users can view script execution status, debugging information, variable values, etc. Establish debugging communication channel through Wi-Fi or network cable, and accept multiple client connections based on TCP protocol. Use Lua's built-in debug library to obtain script runtime information and provide debugging command processing. Support user remote debugging, modify scripts in real time, view variables and execution status, allow users to set breakpoints, single-step execution, etc., provide flexible debugging experience, improve user control over scripts, enhance development and debugging efficiency, reduce dependence on on-site operations through remote debugging, and facilitate problem diagnosis and resolution.

[0067] 3. Modularity and plug-in expansion:

[0068] Modularization and plug-in expansion are implemented based on the seL4 microkernel, which realizes the modularization and dynamic loading of DTU functions, so that different industrial protocols or functional modules (such as Modbus, OPC UA, MQTT, etc.) can be added through plug-in expansion without recompiling the entire system.

[0069] 1. Abstract each functional module of DTU into an independent module, and design different functions in DTU (such as communication protocol stack, data processing, log system, security authentication, etc.) as independent modules for easy management and expansion. Each module is responsible for a specific function independently, such as the Modbus protocol module handles Modbus communication, and the security authentication module is responsible for identity authentication. Use the isolation mechanism of seL4 to ensure that modules communicate through designated interfaces, reducing the risk of inter-module failures. Functional modules can be used as independent libraries to support subsequent dynamic loading and replacement, enhancing the flexibility of the system.

[0070] 2. Modules interact through a unified interface, define a public interface for each module, hide implementation details, and ensure transparency between modules. New modules can be integrated by simply implementing the corresponding interface without modifying the existing code, which improves maintainability and scalability. Modules only provide necessary functions to avoid overly complex interfaces, thereby improving the readability and maintainability of the system.

[0071] 3. The cross-module communication uses the IPC or message passing mechanism of seL4. Each module uses the efficient IPC mechanism provided by seL4 to perform secure message transmission to ensure the security and reliability of data exchange. The modules communicate with each other in an event-driven manner and support asynchronous processing. For example, after receiving the data, the Modbus protocol module sends an event through IPC to notify the main system to process the data, and the main system returns the result after processing. The input and output of each module are designed as message queues to achieve effective communication and coordination between modules.

[0072] A DTU module management method includes DTU monitoring management, remote upload and update management, and the contents are as follows:

[0073] 1. DTU monitoring program module:

[0074] 1. Provide a running environment for user scripts:

[0075] Process the user script through the script parser. Obtain the Lua parser source code and modify the source code. To run the Lua parser based on the seL4 microkernel, you need to remove the dependency on the standard library, such as the I / O library and file system of the Lua parser.

[0076] On seL4, each user-mode task runs as an independent thread, and the Lua parser will also run as an independent thread. Create a Lua service component using the cAmkES component model. Load the Lua parser into the system and assign it specific memory space and permissions.

[0077] Define Lua service component: Define a Lua service in the ADL (Architecture Description Language) of cAmkES, and interact with other services of the seL4 kernel by using the service program defined by cAmkEs.

[0078] Lua supports UTF-8 encoding by default, so users can directly use Chinese variable names without modifying the parser source code. Modify the keyword parsing part of the Lua parser (llex.c), define the Chinese keyword list luaX_tokens_CN, and add Chinese keywords to the lexical analysis of the Lua parser in the luaX_init function. Through this process, users are allowed to write scripts using Chinese keywords, further lowering the programming threshold and improving programming efficiency.

[0079] The script parser communicates with other services (such as network services, serial port services, etc.) through seL4's IPC mechanism. During script execution, when it is necessary to access external resources (such as sending network requests or serial port data), the parser will package the request into an IPC message and send it to the corresponding service process. For example, if the script needs to send data over the network, the parser will generate a request to send data and send the request to the network process through seL4's IPC channel. After receiving the request, the network process is responsible for the actual network data transmission.

[0080] Start the main loop of the parser and listen for external script requests. The main loop runs the parser's event processing mechanism and waits for the user to send the script through the network or serial port interface for parsing and execution.

[0081] When a user uploads a script, the parser receives the upload request through seL4’s IPC mechanism and stores the script code in a predefined memory area.

[0082] The parser then calls the internal load function to load the script code into the parser's runtime environment. If the script contains syntax errors or illegal operations, the parser will return an error message and pass the error back to the process or device that uploaded the script via IPC.

[0083] The parser starts to execute the loaded script. The script execution process needs to parse the script one by one and execute the corresponding instructions according to the design of the parser (such as Lua's bytecode execution).

[0084] 2. Manage user script tasks:

[0085] Manage and schedule multiple script tasks on the seL4 microkernel. The following are detailed implementation steps to ensure efficient implementation of concurrent execution and priority scheduling of script tasks.

[0086] Use seL4's IPC mechanism to receive the uploaded script content and pass it to the script parser process. After the script is uploaded, it is stored in the parser's memory for subsequent execution. Each script runs as an independent user-mode thread, and uses the seL4 system call to create a thread for running script tasks. In each thread, call luaL_newstate() to create a Lua virtual machine, call luaL_loadstring(lua_State*L,const char*s) function to load the user's script task into the Lua virtual machine, and finally call lua_pcall to execute the script task.

[0087] For multiple script tasks, the fixed priority time slice round-robin (FPRR) scheduling algorithm is used to schedule the execution of script tasks: for critical tasks, a higher priority is set. Low-priority tasks get smaller time slices, while high-priority tasks get more time slices to ensure that critical tasks can respond in time. Time slices are allocated to each script task according to priority. The scheduler will schedule each task in turn according to the FPRR algorithm and determine the execution order of tasks according to priority. After the high-priority task is executed in each time slice, it will rotate to the low-priority task.

[0088] 3. Secure isolation of user script tasks:

[0089] In order to ensure the isolation between each user script task and prevent script tasks from interfering with each other and accessing unauthorized resources, the DTU monitoring program module uses the powerful process isolation and permission management mechanism provided by the seL4 microkernel to isolate multiple user script tasks. The following are detailed steps and implementation details to ensure the safe isolation of user script tasks.

[0090] Each user script runs as an independent user-mode thread, ensuring that they are executed in independent memory spaces to avoid memory access and resource conflicts. Each thread creates a new Lua virtual machine instance to serve the script. SeL4's virtual memory allocation function allocates independent virtual memory space to each script thread to ensure that they run in different memory areas to avoid unauthorized memory access. SeL4_VSpace is used to configure different address spaces for each process.

[0091] seL4 strictly controls access to system resources through the capability mechanism. Each script thread is granted only the minimum privileges to access necessary resources. Script threads only have a limited set of capabilities, and by limiting the allocation of capabilities, scripts are prohibited from directly accessing key system resources.

[0092] Implement the network card driver, use the lwip network protocol stack adapted in seL4 to provide network services, and treat the network service as a process. Implement the serial port driver, call the hardware serial port through the seL4 serial port interface, and treat the serial port driver as a serial port service process. Script tasks cannot directly access hardware resources (such as network, serial port, etc.), and all operations must interact with other services (such as network service process, serial port service process) through the seL4 IPC mechanism. The IPC method ensures that the script can only access external resources through predefined interfaces to increase security.

[0093] 4. Error handling in user scripts:

[0094] In the DTU monitoring program running on the seL4 microkernel, error handling is an important part of ensuring system stability and security. When an error occurs in a script task, it is necessary to ensure that the error is correctly captured and handled, and does not affect the operation of other script tasks. The following are detailed error handling steps, covering common situations such as script syntax errors, runtime errors, and memory access violations.

[0095] When the user uploads a script, the parser will load the script content into the Lua virtual machine. When the luaL_loadstring() function is used to load the script, if a syntax error is detected in the script, the error will be fed back to the process that uploaded the script through the IPC provided by seL4, and the loading process will be stopped.

[0096] During script execution, the lua_pcall() function is used to execute script tasks. lua_pcall() can capture runtime errors (such as division by zero errors, undefined variable access, etc.). If a runtime error occurs, the Lua virtual machine returns error information to the process that uploaded the script through IPC and stops executing the task.

[0097] Each script task runs in an independent virtual memory space. If the script attempts to access an unauthorized memory area, the seL4 kernel will trigger a page fault and interrupt the script execution. In this case, the system will capture the error and send the error information to the error handling service through IPC. When an illegal memory access error occurs, the system will immediately terminate the script task, release the resources of the task (such as memory, file handles, etc.), and prevent the error from propagating to other tasks.

[0098] Each script task can only access a limited set of resources (such as network, serial port, etc.), and the resource access rights are controlled by the capability system. If the script attempts to access unauthorized resources, a resource access error will be triggered. seL4 captures unauthorized resource access through the capability system, and the system will send an error message through IPC.

[0099] When an error occurs in a script task (such as a runtime error, memory access violation, etc.), the system will immediately isolate the task and terminate its execution. The error will not affect other running script tasks, ensuring the stability of the system. When the error script task is isolated, the system will release the resources occupied by the task (such as memory, file handles, etc.) to prevent resource leakage.

[0100] In some cases, you can restart the error task as needed. The error handling service can determine whether to restart the task based on the severity of the error. If the error is caused by a temporary failure (such as a network outage), you can try to restart the task. The error information will be fed back to the user who uploaded the script via IPC so that they can understand the specific cause of the error.

[0101] Implement a timer. To prevent script tasks from falling into an infinite loop or occupying CPU resources for a long time, the system can set a timeout detection mechanism. If a task does not return for a long time, the scheduler will mark it as a timeout task and terminate the task.

[0102] 2. Remote upload and update module:

[0103] 1. Upload of user scripts:

[0104] In order to achieve remote upload and security updates, we can receive remote script updates through the wireless interface and ensure the integrity and security of the update process through the security mechanism of seL4. The following are the specific steps to achieve remote updates, dynamic deployment and uninstallation of scripts, and security management using the seL4 capability system.

[0105] Implement Wi-Fi driver based on hardware development board, use lwip network protocol stack to configure Wi-Fi function, user connects to DTU module through mobile device application and sends script file. Establish a TCP server process based on seL4 to receive script upload request from mobile device. User sends Lua script file through mobile device. The server of DTU module receives script file and stores it in the memory area of ​​DTU monitoring program module. The received script file is passed to script parser thread in DTU monitoring module through seL4 IPC mechanism. After uploading, the script file is temporarily stored in DTU memory to prepare for script parser loading. Separate memory space can be allocated for each script task in seL4.

[0106] The security of the update package transmission on the network is ensured by TLS (Transport Layer Security). The mbedTLS lightweight TLS library is used to encrypt the transmitted data. After receiving the script update package, the update package is verified using a hash function (SHA-256). The server will attach a checksum value (digital signature) to the update package. After receiving the update package, the DTU module calculates the hash value and compares it with the hash value provided by the server to verify whether the data has been tampered with. If a digital signature is used, after receiving the script update package, the signature is verified using the public key to ensure that the source of the data is credible and has not been tampered with.

[0107] 2. Update of user scripts:

[0108] When a new script update package is received and passes integrity verification, the system will dynamically deploy a new script task. A new user-mode thread is created through seL4, and capability resources are allocated to ensure that the new script can run safely. When updating a script task, the old script must be safely uninstalled to ensure that the new script can be deployed correctly.

[0109] The system provides a script uninstallation function, allowing users to send uninstallation requests through the wireless interface. After receiving the request, the system terminates the corresponding script task and releases the resources it occupies (such as memory, network handles, etc.). When uninstalling the script, the seL4 kernel interface is called to ensure that the resources of the old script (such as memory, network handles, etc.) are correctly released to prevent resource leakage.

[0110] 3. Debugging of user scripts:

[0111] In order to debug the script in the DTU module, a debugging interface needs to be implemented so that users can remotely connect to the DTU module to view the script execution status, debugging information, variable values, etc., and even modify the script in real time or interrupt debugging. The following are detailed implementation steps, covering the design of the debugging interface, the acquisition of debugging data, the remote debugging mechanism, and the transmission of debugging information.

[0112] A debugging communication channel can be established through a wireless interface Wi-Fi or a network cable connection. A connection is established based on the TCP protocol. A server thread is established to accept multiple client connections and handle debugging requests from different clients through different ports. An independent debugging connection needs to be created for each client.

[0113] Lua provides a built-in debug library that can be used to obtain the runtime information of the script, including stack information, variable status, execution instructions, etc. We can use this library to debug the script. Users can view and modify local or global variable values ​​in Lua scripts through the debugging interface. debug.getlocal() and debug.setlocal() can be used to read and set variable values. When the client requests debugging information, the DTU module needs to send the debugging information to the client through the network connection. Usually, the debugging information includes the current line of script execution, local variable values, global status, etc. The client can send debugging commands to the DTU module, such as setting breakpoints, single-step execution, viewing variable values, or modifying variable values. After receiving the debugging command, the system parses the command and performs the corresponding operation.

[0114] 3. Modularity and plug-in expansion:

[0115] The DTU module is used to implement modularization and plug-in expansion based on the seL4 microkernel, and the modularization and dynamic loading of DTU functions are realized, so that different industrial protocols or functional modules (such as Modbus, OPC UA, MQTT, etc.) can be added through plug-in expansion without recompiling the entire system.

[0116] 1. Abstract each functional module of DTU into independent modules:

[0117] The core of modular design is to decouple different functions in DTU (data terminal unit) (such as communication protocol stack, data processing, log system, security authentication, etc.) so that each functional module exists independently for easy management and expansion.

[0118] Identify functional modules such as communication protocol stack, data processing, logging system, security authentication, network interface, etc. Each module should be responsible for a specific function independently. For example, the Modbus protocol stack module focuses on processing Modbus protocol communications, and the security authentication module is responsible for user and device identity authentication.

[0119] Each functional module encapsulates its unique logic and data. For example, the Modbus protocol module encapsulates the processing of serial port or TCP data, and the parsing and construction of Modbus frames.

[0120] Using seL4's isolation mechanism, when designing modules, ensure that each module can only communicate with other modules through designated interfaces. In this way, errors or failures of modules will not affect the normal operation of other modules.

[0121] Each functional module can be used as an independent library (such as Rust's crate or C / C++'s dynamic link library) to facilitate subsequent dynamic loading and replacement.

[0122] Modules cannot share memory directly, and should communicate through message passing or interfaces to ensure system security.

[0123] 2. Modules interact through a unified interface:

[0124] The key to modularity is that modules can interact through a unified interface, making the implementation details of each module transparent to other modules. The interface should define the functionality of the module, not its internal implementation.

[0125] Define a public interface for each module. The interface of the communication module can define the method of sending and receiving data, and the interface of the log module can define the API for recording logs. In this way, when the system needs to expand a new protocol stack or module, it only needs to implement the corresponding interface without modifying the code of other parts.

[0126] Modules interact with each other through interfaces and cannot directly call each other's internal logic to ensure the maintainability and scalability of the code. Each module only provides necessary functions to avoid overly complex interfaces.

[0127] 3. Cross-module communication uses seL4's IPC or message passing mechanism:

[0128] Since each module is isolated, they must communicate through a secure message passing mechanism. seL4 provides an efficient IPC (inter-process communication) mechanism to enable data exchange between modules.

[0129] Use seL4's IPC mechanism to implement cross-module message passing. Each module cannot directly access each other's memory space, and can only pass data through IPC. Design the input and output of each module as a message queue. When a module completes a task, put the result in the queue and use seL4's semaphore mechanism seL4_send() and seL4_wait() to notify other modules to process.

[0130] The modules communicate with each other in an event-driven manner. For example, after receiving a data packet, the Modbus protocol stack can send an event through IPC to notify the main system to process the data. After processing the data, the main system transmits the processing results back to the Modbus module through IPC.

[0131] 4. DTU module deployment implementation example

[0132] This embodiment describes an industrial gateway based on the seL4 microkernel and the T507 development board as a specific implementation method for deploying the invention. The industrial gateway connects the cloud platform and the IoT devices, and has protocol conversion, data processing, data forwarding and security protection functions. This embodiment shows how the invention can be applied in an actual industrial environment.

[0133] The Allwinner T507 development board is a hardware platform for industrial IoT gateways. It has powerful processing capabilities and rich peripheral interfaces (such as RS485, Ethernet, 4G / 5G, Wi-Fi, etc.), which can meet a variety of industrial protocols and communication requirements.

[0134] seL4 is a formally verified high-security microkernel suitable for deployment in industrial systems with high security requirements. In this gateway, the seL4 microkernel provides reliable isolation and security for the DTU module, ensuring security during data processing and transmission.

[0135] First, hardware initialization is required. Start the seL4 microkernel on the T507 development board, initialize all communication interfaces (such as RS485, Ethernet, 4G / 5G, Wi-Fi, etc.), and implement the drivers of these communication interfaces to call the hardware interfaces to ensure that the device can communicate normally with the gateway.

[0136] Deploy the seL4 microkernel to the T507 development board and perform necessary security configurations. Modify and transplant the seL4 microkernel's hardware dependency based on T507 to ensure that the operating system can use the hardware resources of the T507 development board and provide complete permission management and security isolation.

[0137] Users can deploy and run their own script tasks on the industrial gateway through the DTU monitoring program module to implement user-defined functions. Users can configure the industrial gateway by writing scripts, such as network parameters, data processing methods, etc.

[0138] Through the DTU module, users can customize scripts to process data sent from the cloud platform and data uploaded by the device to ensure the legitimacy of the data, avoid all processing tasks in the cloud, reduce the burden on the cloud and improve processing performance.

[0139] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art that are not invented by the present invention. The specification and examples are to be considered exemplary only, and the true scope and spirit of the present invention are indicated by the following claims.

[0140] It should be understood that the present invention is not limited to the exact construction that has been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A DTU module management system, characterized in that: Including monitoring program module and remote upload and update module; Monitoring program module: provides a running environment for user scripts, manages user script tasks, isolates user script tasks securely, and handles errors in user scripts; Remote upload and update module: user script upload, user script update and user script debugging. Different functions in DTU are designed as independent modules, each module is responsible for specific functions independently, and the seL4 isolation mechanism is used to ensure that modules communicate through designated interfaces. Functional modules can be used as independent libraries to support subsequent dynamic loading and replacement; modules interact through a unified interface, and a public interface is defined for each module. New modules can be integrated by simply implementing the corresponding interface.

2. A DTU module management system according to claim 1, characterized in that: The monitoring program modules include: Provides a running environment for user scripts: processes user scripts through the Lua parser, creates independent Lua service components, and integrates with the seL4 microkernel; provides a safe and efficient script execution environment, and allows users to write scripts using Chinese variable names; communicates with other services through IPC to access external resources; Manage user script tasks: Manage and schedule multiple user script tasks, use a fixed-priority time slice round-robin scheduling algorithm to ensure concurrent running and efficient scheduling of script tasks, prioritize key tasks, and run each script task as an independent thread; Secure isolation of user script tasks: Utilize seL4's process isolation and permission management mechanism to ensure that each user script runs in an independent memory space and restrict its access rights; through capability mechanisms and IPC, restrict the interaction between scripts and external resources; Error handling of user scripts: Capture and handle various errors in script execution, and feedback error information through IPC; avoid resource leakage through timely isolation and resource release, and try to restart the failed task when necessary.

3. A DTU module management system according to claim 1, characterized in that: The remote upload and update module includes: Upload of user scripts: implement Wi-Fi driver, configure lwip network protocol stack, allow users to connect to DTU module through mobile devices and upload script files, establish TCP server process based on seL4 to receive script upload requests, pass received script files to script parser thread through seL4 IPC mechanism, use TLS to ensure data transmission security, and verify data integrity and source through hash check and digital signature; provide remote script upload capability, so that users can easily update scripts and temporarily store uploaded script files for subsequent parsing and execution; User script update: After receiving a new script update package, integrity verification is performed and new script tasks are dynamically deployed. New user-mode threads are created and capability resources are allocated to ensure the safe execution of new scripts. Dynamic deployment of new script tasks is supported to achieve real-time script updates. Users are allowed to send uninstall requests through the wireless interface and release resources occupied by old scripts to ensure that old scripts are safely uninstalled before new scripts are deployed to avoid resource leakage. Debugging of user scripts: Implement remote debugging interface, users can view script running status; establish debugging communication channel through Wi-Fi or network cable, accept multiple client connections based on TCP protocol; use Lua's built-in debug library to obtain script runtime information, and provide debugging command processing; support user remote debugging, real-time script modification, view variables and execution status, and allow users to set breakpoints and single-step execution.

4. A DTU module management system according to claim 1, characterized in that: Cross-module communication uses seL4's IPC or message passing mechanism. Each module performs secure message passing through the efficient IPC mechanism provided by seL4. Modules communicate with each other in an event-driven manner and support asynchronous processing.

5. A DTU module management method, installed in the DTU module management system according to any one of claims 1 to 4, characterized in that: The method in the monitoring program module to provide a running environment for user scripts is: Process the user script through the script parser, obtain the Lua parser source code, modify the source code, and run the Lua parser based on the seL4 microkernel; On seL4, each user-mode task runs as an independent thread, and the Lua parser will also run as an independent thread; Create a Lua service component using the cAmkES component model; load the Lua parser into the system and assign it specific memory space and permissions; Define Lua service component: define a Lua service in the ADL of cAmkES, and interact with other services of the seL4 kernel by using the service program defined by cAmkEs; Lua supports UTF-8 encoding by default, and users can directly use Chinese variable names; modify the keyword parsing part of the Lua parser (llex.c), define the Chinese keyword list luaX_tokens_CN, and add Chinese keywords to the lexical analysis of the Lua parser in the luaX_init function; The script parser communicates with other services through the IPC mechanism of seL4. During the script execution process, when it needs to access external resources, the parser will package the request into an IPC message and send it to the corresponding service process; start the main loop of the parser, listen for external uploaded script requests, and run the event processing mechanism of the parser in the main loop, waiting for the user to send the script through the network or serial port interface for parsing and execution; When a user uploads a script, the parser receives the upload request through the seL4 IPC mechanism and stores the script code in a predefined memory area; the parser then calls the internal load function to load the script code into the parser's runtime environment; If the script contains syntax errors or illegal operations, the parser will return an error message and transmit the error back to the process or device that uploaded the script via IPC; The parser starts to execute the loaded script. The script execution process needs to parse the script one by one and execute the corresponding instructions according to the design of the parser.

6. The DTU module management method according to claim 5, characterized in that: The method for managing user script tasks in the monitoring program module is: Use seL4's IPC mechanism to receive the uploaded script content and pass it to the script parser process; After the script is uploaded, it is stored in the parser's memory for subsequent execution. Each script runs as an independent user-mode thread, and uses the seL4 system call to create a thread for running the script task. In each thread, luaL_newstate() is called to create a Lua virtual machine, and the luaL_loadstring(lua_State*L,const char*s) function is called to load the user's script task into the Lua virtual machine. Finally, lua_pcall is called to execute the script task. For multiple script tasks, a fixed-priority time slice round-robin scheduling algorithm is used to schedule the execution of script tasks: for critical tasks, a higher priority is set so that low-priority tasks get smaller time slices, while high-priority tasks get larger time slices, ensuring that critical tasks can respond in a timely manner; time slices are allocated to each script task according to priority; the scheduler will schedule each task in turn according to the FPRR algorithm and determine the execution order of tasks based on priority; high-priority tasks will be rotated to low-priority tasks only after they are executed within each time slice.

7. The DTU module management method according to claim 5, characterized in that: The error handling steps of the user script are as follows: When the user uploads a script, the parser will load the script content into the Lua virtual machine. When the luaL_loadstring() function is used to load the script, if a syntax error is detected in the script, the error will be fed back to the process that uploaded the script through the IPC provided by seL4, and the loading process will be stopped. During script execution, the lua_pcall() function is used to execute script tasks. lua_pcall() can capture runtime errors. If a runtime error occurs, the Lua virtual machine returns error information to the process that uploaded the script through IPC and stops executing the task. Each script task runs in an independent virtual memory space. If a script attempts to access an unauthorized memory area, the seL4 kernel will trigger a page fault and interrupt the script execution. The system will capture the error and send the error information to the error handling service through IPC. When an illegal memory access error occurs, the system immediately terminates the script task, releases the task's resources, and prevents the error from propagating to other tasks; Each script task can only access a limited set of resources; if the script attempts to access unauthorized resources, a resource access error will be triggered; seL4 captures unauthorized resource access through the capability system, and the system will send an error message through IPC; When an error occurs in a script task, the system will immediately isolate the task and terminate its execution. The error will not affect other running script tasks. When the error script task is isolated, the system will release the resources occupied by the task to prevent resource leakage. The error handling service determines whether to restart the task based on the severity of the error; if the error is caused by a temporary failure, you can try to restart the task; Error information will be fed back to the user who uploaded the script via IPC; Implement a timer. To prevent script tasks from falling into an infinite loop or occupying CPU resources for a long time, the system can set a timeout detection mechanism. If a task does not return for a long time, the scheduler will mark it as a timeout task and terminate the task.

8. The DTU module management method according to claim 5, characterized in that: The upload method for the user script is: Implement Wi-Fi driver based on hardware development board, use lwip network protocol stack to configure Wi-Fi function, users connect to DTU module through mobile device application and send script file; A TCP server process is established based on seL4 to receive script upload requests from mobile devices; The user sends the Lua script file via a mobile device; The server side of the DTU module receives the script file and stores it in the memory area of ​​the DTU monitoring program module; The received script file is passed to the script parser thread in the DTU monitoring module through the seL4 IPC mechanism; After the script file is uploaded, it will be temporarily stored in the DTU memory to prepare for the script parser to load it. In seL4, an independent memory space is allocated for each script task; Use the mbedTLS lightweight TLS library to encrypt the transmitted data; after receiving the script update package, use the hash function to verify the update package; the server will add a verification value to the update package; after receiving the update package, the DTU module calculates the hash value and compares it with the hash value provided by the server to verify whether the data has been tampered with; if a digital signature is used, after receiving the script update package, use the public key to verify the signature to ensure that the source of the data is credible and has not been tampered with.

9. The DTU module management method according to claim 5, characterized in that: The steps for debugging a user script are as follows: Establish a debugging communication channel through the wireless interface Wi-Fi or network cable connection, establish a connection based on the TCP protocol, establish a server thread to accept multiple client connections, and process debugging requests from different clients through different ports. It is necessary to create an independent debugging connection for each client; Lua provides a built-in debug library to obtain the runtime information of the script; users can view and modify the local or global variable values ​​in the Lua script through the debug interface; debug.getlocal() and debug.setlocal() are used to read and set variable values; When the client requests debugging information, the DTU module needs to send the debugging information to the client through the network connection; the client sends a debugging command to the DTU module, and after the system receives the debugging command, it parses the command and performs corresponding operations.

10. A method for deploying a DTU module management system, deploying the DTU module management system described in any one of claims 1 to 4 on an industrial gateway, characterized in that: The following steps are involved: The first step is to initialize the hardware. Start the seL4 microkernel on the development board, initialize all communication interfaces, and implement the drivers of these communication interfaces to call the hardware interfaces to ensure that the device can communicate normally with the gateway. Step 2: Deploy the seL4 microkernel to the development board and perform necessary security configurations. Modify and transplant the seL4 microkernel's hardware dependency based on the development board to ensure that the operating system can use the development board's hardware resources and provide complete permission management and security isolation. Step 3: Users deploy and run their own script tasks on the industrial gateway through the DTU monitoring program module to implement user-defined functions. Users can configure the industrial gateway by writing scripts; user-defined scripts process the data sent by the cloud platform and the data uploaded by the device.

Images