Dynamic service scheduling device and method of intelligent gateway

Abstract

The invention discloses a dynamic service scheduling device and method for an intelligent gateway, and the device comprises a software layer which comprises a service arrangement layer, a service management layer, and a service data layer. The service arrangement layer carries out service demand hierarchical analysis and process binding, and completes equipment traffic classification and preparation work of cross-process method calling; the service management layer realizes acquisition of resource data and planning of an optimal service deployment path, generates a service construction linked list and stores the service construction linked list in a shared memory; and the service data layer completes starting of a service container and directional forwarding of flow to form a dynamic service chain closed loop so as to realize dynamic scheduling and on-demand deployment of Internet of Things equipment services. According to the invention, the software layer adopts a three-layer architecture to realize function decoupling, and each layer can dynamically adjust the service according to the actual demand, thereby meeting the personalized service demands of different Internet of Things devices, and improving the flexibility and adaptability of the gateway. Resource waste is avoided, efficient utilization of hardware resources is ensured, and the operation cost of the Internet of Things system is reduced.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) gateway technology, and more specifically, to a dynamic service scheduling device and method for a smart gateway. Background Technology

[0002] With the rapid development of IoT technology, the number of IoT devices has surged, and application scenarios have become increasingly complex, placing higher demands on the functionality of IoT gateways. Traditional IoT gateways mostly adopt a static function configuration mode, with fixed service functions, which cannot be dynamically adjusted according to device traffic characteristics, business needs, and resource status, making it difficult to meet the differentiated service needs of different devices.

[0003] Meanwhile, traditional gateways suffer from numerous problems in cross-layer collaboration and process communication. First, their service functions are fixed and cannot be dynamically adjusted based on device traffic characteristics, business needs, and resource status, making it difficult to meet the differentiated service requirements of various devices such as industrial sensors, smart home terminals, and surveillance cameras. Second, functional layers are often isolated from each other, relying on fixed communication protocols such as HTTP and RPC for data interaction. This not only results in high development costs and poor compatibility but also high communication latency, failing to meet the millisecond-level real-time requirements of IoT scenarios. Third, when gateways face resource overload, container failures, or network outages, traditional gateways lack effective fault self-healing mechanisms and active-active switching capabilities, making them prone to service interruptions and data loss, impacting the reliability and stability of IoT systems.

[0004] Therefore, existing technologies have many problems and need further improvement and development. Summary of the Invention

[0005] (I) Purpose of the invention: In order to solve the problems existing in the prior art, the purpose of the present invention is to provide a dynamic service scheduling device and method for smart gateways. Through layered architecture design, cross-process method calls and efficient collaboration mechanisms, dynamic scheduling and on-demand deployment of services are realized, thereby improving the flexibility, real-time performance and reliability of the gateway and meeting the differentiated needs of complex Internet of Things scenarios.

[0006] (II) Technical Solution: In order to solve the above technical problems, this technical solution provides a dynamic service scheduling device for intelligent gateways, including a software layer, which includes a three-layer architecture of service orchestration layer, service management layer and service data layer; The service orchestration layer performs layered parsing of service requirements and process binding, and completes the classification of device traffic and preparation for cross-process method calls; The service management layer acquires resource data and plans the optimal service deployment path, generates a service construction list, and stores it in shared memory. The service data layer completes the startup of service containers and the targeted forwarding of traffic, forming a dynamic service chain closed loop, enabling dynamic scheduling and on-demand deployment of IoT device services.

[0007] Preferably, the service orchestration layer includes a traffic classifier and a Hook injection submodule; The traffic classifier analyzes the uplink traffic of IoT devices using deep packet inspection technology, generates classified messages according to multiple dimensions and carries process identifiers; The Hook injection submodule injects the Hook function containing the server into the resource scheduling process of the service management layer through the Inject injector, registers the scheduling methods required for resource scheduling into shared memory, and builds a bridge for cross-process calls between the service orchestration layer and the service management layer.

[0008] Preferably, based on the deep packet inspection results, classified messages are generated according to four dimensions: device attributes, protocol type, data characteristics, and business scenarios. The classified messages adopt a structure of fixed header, variable label, and raw data, which includes multi-dimensional classification results and carries service process identifiers.

[0009] Preferably, the Hook function includes a resource query interface, process binding rules, and a service priority mapping table, and enables direct cross-process method invocation through a shared memory mapping mechanism.

[0010] Preferably, the service management layer includes a resource queryer, a service controller, and a proxy communication submodule; The resource queryer directly calls the hardware layer interface to collect resource data from the gateway and edge nodes in real time and stores it in a distributed database. The service controller, based on the classified message requirements and real-time resource data, calls a dynamic programming multi-segment graph algorithm to calculate the globally optimal service deployment path, generates a service construction linked list, and writes it into shared memory; The proxy communication submodule communicates with the proxy through the IBinder mechanism, receives classified messages and returns a memory pointer to the service construction linked list.

[0011] Preferably, the dynamic programming multi-segment graph algorithm specifically includes: Step 201: Construct a multi-segment graph model to transform the service deployment path into a directed weighted multi-segment graph; Step 202: Use reverse dynamic programming to derive the optimal path from back to front; Step 203: After generating the optimal path, connect it with the service building linked list.

[0012] Preferably, the service construction linked list adopts a linear linked structure and is stored in shared memory in binary form, including a head node, service nodes, and a tail node. Each node contains a basic attribute segment and a functional extension segment, and the association between nodes is realized through a pointer field.

[0013] Preferably, the service data layer includes a container engine and a traffic forwarder; The container engine parses the service building list in shared memory, calls the Docker API to dynamically start the corresponding IoT security service container, and configures virtual bridges and network isolation rules between containers. The traffic forwarder issues flow tables based on the OpenFlow protocol and directs traffic to the corresponding service container according to the process identifier of the classified packets and the port mapping relationship of the service building linked list.

[0014] Preferably, it also includes a cross-layer collaborative unit, which includes a fault self-healing module and a mode switching module; The fault self-healing module monitors the running status of the service container in real time. When an abnormality is detected in the service container, it re-injects the resource scheduling process of the service management layer through the Hook function, calls the service backup linked list and other operations, restarts the container on the backup hardware resources, and reconfigures the traffic forwarding rules. The mode switching module supports flexible switching between local autonomy and cloud collaboration modes, ensuring normal scheduling of local services during network outages and data synchronization after network recovery, thus guaranteeing system continuity in complex network environments.

[0015] Preferably, it also includes a hardware layer, which includes a network interface module, including an Ethernet port, Wi-Fi, TCP, and 4G / 5G full network compatibility.

[0016] A dynamic service scheduling method for smart gateways, applicable to dynamic service scheduling devices for smart gateways, specifically includes: Step 1: The service orchestration layer performs service requirement layering and process binding, completing the classification of device traffic and preparation for cross-process method calls; Step 2: The service management layer acquires resource data and plans the optimal service deployment path, generates a service construction linked list, and stores it in shared memory; Step 3: The service data layer completes the startup of the service container and the targeted forwarding of traffic, forming a dynamic service chain closed loop, realizing the dynamic scheduling and on-demand deployment of IoT device services.

[0017] (III) Beneficial Effects: This invention provides a dynamic service scheduling device and method for a smart gateway. First, the three-layer software architecture achieves functional decoupling, allowing each layer to dynamically adjust services according to actual needs. The service orchestration layer can generate differentiated service chains based on device traffic characteristics, and the service data layer can dynamically start or stop service containers to meet the personalized service needs of different IoT devices, improving the gateway's flexibility and adaptability. Second, through Hook function injection and shared memory technology, direct invocation of cross-process methods is achieved without relying on complex communication protocols, reducing protocol encapsulation and parsing in the data transmission process, significantly reducing cross-layer communication latency, and meeting the real-time requirements of IoT scenarios. Furthermore, the fault self-healing unit of the cross-layer collaborative unit can quickly restore services when service containers are abnormal, avoiding service interruption; the dual-active switching unit supports flexible switching between local and cloud modes, ensuring that the gateway can still operate normally and prevent data loss in extreme situations such as network interruptions, improving the reliability and stability of the IoT system. Finally, the service management layer collects resource data in real time and calls dynamic programming algorithms to generate the optimal service deployment path, avoiding resource waste, ensuring efficient utilization of hardware resources, and reducing the operating costs of the IoT system. Attached Figure Description

[0018] Figure 1 This is a system structure diagram of the dynamic service scheduling device of the intelligent gateway of the present invention; Figure 2 This is a schematic diagram of the dynamic service scheduling device of the intelligent gateway of the present invention; Figure 3 This is a flowchart of the steps in the software layer of the present invention; Figure 4 This is a flowchart illustrating the steps involved in using a dynamic programming multi-segment graph algorithm to calculate the globally optimal service deployment path. Detailed Implementation

[0019] The present invention will be further described in detail below with reference to preferred embodiments. More details are set forth in the following description in order to provide a full understanding of the present invention. However, the present invention can obviously be implemented in many other ways different from those described herein. Those skilled in the art can make similar extensions and derivations based on actual application situations without departing from the spirit of the present invention. Therefore, the scope of protection of the present invention should not be limited by the content of this specific embodiment.

[0020] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that these drawings are for illustrative purposes only and are not drawn to scale, and should not be construed as limiting the actual scope of protection of the present invention.

[0021] A dynamic service scheduling device for a smart gateway, such as Figure 1 , Figure 2As shown, the device comprises a hardware layer, a software layer, and a cross-layer collaboration unit. The hardware layer provides the basic hardware support for the entire device and serves as the carrier for the software layer's functionalities. The software layer consists of a three-layer architecture: a service orchestration layer, a service management layer, and a service data layer. Dynamic service scheduling is achieved through cross-process method calls. The cross-layer collaboration unit breaks down the isolation between the hardware and software layers, and between different layers within the software layer, ensuring the continuity and reliability of service orchestration.

[0022] Specifically, the hardware layer includes a processor module, a network interface module, and a storage module.

[0023] The processor module is equipped with an ARM architecture processor, which supports multi-process concurrent operation and meets the needs of simultaneous execution of multiple tasks such as service orchestration, resource scheduling, and container management. It integrates a memory controller and a shared memory submodule, which are specifically used for storage service scheduling methods and real-time resource data, providing a hardware foundation for cross-process data sharing and efficient invocation.

[0024] The network interface module includes multiple network interfaces, such as Ethernet, Wi-Fi, TCP (Transmission Control Protocol), and 4G / 5G full network compatibility, to meet the traffic access and classified message transmission needs of various types of IoT devices. When the wired network is interrupted, the 4G / 5G module can ensure the upload of critical data, ensuring the diversity and stability of data transmission.

[0025] The IoT devices include sensors, cameras, and smart switches. The categorized messages are encapsulated according to device type, application protocol type, and data sensitivity level.

[0026] The storage module is configured with an SSD cache and a local database to persistently store service chain rules and device communication logs, ensuring smooth data retrieval and analysis. The SSD cache is used for fast reading of frequently accessed service chain rules, improving service response speed. The local database is used for persistent storage of device communication logs and service chain rule backups, ensuring data traceability and rapid service recovery after network restoration.

[0027] The software layer, serving as the core functional implementation component, features a clearly defined and collaborative structure, comprising a three-layer architecture: a service orchestration layer, a service management layer, and a service data layer. The service orchestration layer performs layered parsing of service requirements and process binding, classifying device traffic and preparing for cross-process method calls. The service management layer acquires resource data and plans the optimal service deployment path, generating a service construction list and storing it in shared memory. The service data layer starts service containers and forwards traffic in a targeted manner, forming a dynamic service chain loop that enables dynamic scheduling and on-demand deployment of IoT device services.

[0028] Accordingly, the present invention also provides a dynamic service scheduling method for a smart gateway, applicable to the dynamic service scheduling device for the aforementioned smart gateway, such as... Figure 3 As shown, the specific steps include: Step 1: The service orchestration layer performs service requirement layering and process binding, completing the classification of device traffic and preparation for cross-process method calls.

[0029] Step 2: The service management layer acquires resource data and plans the optimal service deployment path, generates a service construction list, and stores it in shared memory.

[0030] Step 3: The service data layer completes the startup of the service container and the targeted forwarding of traffic, forming a dynamic service chain closed loop, realizing the dynamic scheduling and on-demand deployment of IoT device services.

[0031] The service orchestration layer is responsible for traffic classification and service requirement parsing, including a traffic classifier and a Hook injection submodule.

[0032] The service requirement layering analysis adopts a three-level decomposition model: user requirement analysis, business layer requirement analysis, and resource layer requirement analysis. Each layer outputs structured parameters, forming a mapping chain from abstract requirements to quantitative indicators.

[0033] The user requirement parsing refers to the process of extracting core requirement keywords from natural language or templated requirements submitted by users through API / console using NLP tools, mapping them to preset requirement types, and outputting them in JSON format.

[0034] The business layer requirement parsing generates a service chain component list based on user needs and assigns business attributes to each component. Service chains are generated by matching preset service templates with `service_type`; high-frequency scheduling is set for the anomaly detection component; and mandatory encryption is set for the alarm push component.

[0035] The resource layer requirement analysis transforms business attributes into quantitative constraints on hardware resources, forming a resource prescription for process scheduling.

[0036] Specifically, for CPU requirements, high-freq processes are bound to physical cores to avoid scheduling switches; I / O-intensive processes are allowed to be scheduled using hyper-threading. For memory requirements, encryption services require ≥256MB of memory; general detection services require ≥128MB of memory. For network requirements, real-time services are bound to low-latency network cards, such as Ethernet preferred over 4G, with a bandwidth ≥1Mbps; high-security services only allow access to VLAN-isolated networks.

[0037] The physical core is a real hardware computing unit integrated on a CPU processor. Powered by an ARM architecture processor, it supports multi-process concurrent operation, providing native computing capabilities for tasks such as service orchestration and resource scheduling for the smart gateway. The physical core possesses completely independent hardware resources, eliminating the performance loss caused by resource sharing between cores. Its operational stability and instruction execution efficiency are far superior to those of logical cores.

[0038] For services with extremely high real-time requirements, the high freq process is strongly bound to the physical core to avoid switching between different cores, eliminate context switching overhead, and ensure ultimate stability and response speed.

[0039] Based on the resource layer parsing results, a strong binding between processes and resources is achieved through the Linux process scheduling mechanism, ensuring that services run on matching hardware.

[0040] The traffic classifier analyzes uplink traffic from IoT devices using deep packet inspection (DPI) technology, generating categorized messages across multiple dimensions and carrying process identifiers to provide a basis for differentiated service scheduling. Specifically, based on the DPI analysis results, categorized messages are generated according to four dimensions: device attributes, protocol type, data characteristics, and business scenario, ensuring the comprehensiveness and accuracy of the categorization.

[0041] The process of generating categorized messages based on device attributes involves device type identification based on MAC addresses. The device database pre-defines the mapping between device manufacturer MAC prefixes and types, and dynamically updates the database using Organization Unique Identifiers (OUIs). Each MAC address is bound to a device attribute tag, including device type, associated scenario, and criticality level. For example, a device with MAC address 00:1A:2B:3C:4D:5E is tagged as (Type: PLC, Scenario: Safe Electricity Use, Criticality: Core).

[0042] The process of generating categorized messages based on protocol type involves labeling the protocol type based on the DPI identification results. Composite protocols are further subdivided; for example, HTTP protocols are labeled with subtypes based on URL paths: HTTP / api / alert represents alarm data reporting; HTTP / api / config represents device configuration modification; and HTTP / api / log represents regular log uploads.

[0043] The process of generating categorized messages based on data characteristics involves parsing the payload content and matching sensitive fields to classify the data into four sensitivity levels. L4 represents extremely high sensitivity and includes device keys, user privacy information, and control commands. L3 represents high sensitivity and includes alarm information and fault codes. L2 represents medium sensitivity and includes device status data. L1 represents low sensitivity and includes heartbeat packets and empty messages.

[0044] The sensitive field library includes preset sensitive keywords and regular expressions, and users can add their own.

[0045] The process of generating categorized messages based on business scenarios involves combining device type and data content to map them to specific business scenario tags.

[0046] Each message carries the process identifier (PID) of the corresponding service process to ensure the accuracy of subsequent service matching. For example, highly sensitive data is matched with encrypted services, and ordinary data is matched with basic filtering services.

[0047] The classification message adopts a structure of fixed header, variable label, and raw data, which includes multi-dimensional classification results and carries service process identifiers to ensure that downstream layers can quickly parse and match.

[0048] For example, in a lightning protection monitoring scenario, the DPI resolves the MAC address to 00:1A:2B:3C:4D:5E, indicating a device type of SPD protector and a proprietary lightning protection protocol. The payload contains leak_current=30mA, representing an L3 sensitivity level, and the business scenario is lightning protection monitoring.

[0049] The classified message is DstPID=30001; 0x01=SPD, 0x02=Private V1.0, 0x03=L3, 0x04=Lightning protection monitoring. The service data layer parses PID=30001, starts the lightning protection alarm container, and executes the service chain of data encryption, local power failure control, and cloud alarm.

[0050] The Hook injection submodule injects the Hook function containing the server into the resource scheduling process of the service management layer through the Inject injector, registers the scheduling methods required for resource scheduling in shared memory, builds a bridge for cross-process calls between the service orchestration layer and the service management layer, and avoids scheduling delays caused by traditional protocol dependencies.

[0051] The Hook function includes a resource query interface, process binding rules, and a service priority mapping table, and enables direct cross-process method invocation through a shared memory mapping mechanism.

[0052] The scheduling method includes a multi-dimensional real-time resource status query method, a service process hardware resource binding method, a service priority dynamic scheduling method, a globally optimal deployment path planning method, a service construction linked list generation and synchronization method, and a cross-layer collaborative fault self-healing triggering method. The scheduling method covers the entire process of resource scheduling from data acquisition, demand mapping, path planning, execution deployment to fault recovery.

[0053] The multi-dimensional real-time resource status query method obtains the real-time hardware resource status of the gateway local and edge nodes, providing data support for scheduling decisions. This method includes a resource query module in the service management layer that directly calls the hardware layer interface via static methods to collect key indicators such as CPU utilization, memory usage, network bandwidth, and disk I / O. The raw data is then converted into a unified format and stored in a distributed database. A Hook function contains a resource query interface, serving as the core entry point for cross-process resource data interaction and supporting fast cross-process reading.

[0054] The described service process hardware resource binding method establishes a strong association between service processes and hardware resources, ensuring that services run in a matching hardware environment. Based on the mapping rules between service types and resource requirements, this method defines differentiated scheduling rules for CPU, memory, and network. Through the Linux process scheduling mechanism, it strongly binds service processes to specific CPU cores, network interfaces, and other hardware resources, avoiding performance losses caused by scheduling switches.

[0055] The service priority dynamic scheduling method defines the execution order of different services, ensuring that critical services occupy resources first. This method defines service priority levels through a service priority mapping table. The priority level is linked to the PriorityLevel field of the service construction list, determining the execution order of container startup and traffic forwarding. When resources are scarce, the resource needs of high-priority services are prioritized, ensuring the scheduling priority of critical services.

[0056] The globally optimal deployment path planning method calculates the optimal service deployment path under multiple nodes, service types, and resource constraints. This method constructs a multi-segment graph model, transforming the service deployment path into a directed weighted multi-segment graph where vertices represent service nodes and edges represent resource costs, communication costs, and reliability costs. Inverse dynamic programming is used to derive the minimum cost from each node to the destination from the end point, backtracking to obtain the globally optimal path. The deployment path is dynamically adjusted based on real-time resource status to avoid resource overload or waste.

[0057] The service construction linked list generation and synchronization method transforms the optimal deployment path into a standardized data structure, enabling efficient transmission of cross-layer service scheduling instructions. This method converts the globally optimal path into a linear linked structure containing a head node, service nodes, and a tail node, stored in shared memory in binary form. The service data layer directly reads and parses the linked list content through memory mapping, starts the corresponding service container, and forms a dynamic service chain closed loop.

[0058] When a service container malfunctions, the cross-layer collaborative fault self-healing triggering method quickly initiates the fault self-healing process to ensure service continuity. This method monitors the service container's running status in real time. When a container malfunction is detected, it re-injects the resource scheduling process of the service management layer through a Hook function, calls the service construction linked list backed up on the server side, restarts the container on backup hardware resources, and reconfigures traffic forwarding rules to achieve rapid service recovery and avoid service interruption.

[0059] Specifically, the resource query interface directly calls the hardware layer interface via static methods to obtain key indicators such as CPU, memory, and network bandwidth, converting the raw resource data into a unified format for cross-process parsing. This resource query interface serves as the query entry point for interaction between the Hook function and the hardware and service management layers, dynamically obtaining the real-time resource status of gateways and edge nodes to provide data support for service scheduling decisions.

[0060] Process binding rules define the mapping logic between categorized packets and target service processes, ensuring that traffic from different types of devices is directed to the matching service container. These process binding rules are stored in shared memory as key-value pairs and can be dynamically modified via the updateRule(key, value) interface. For example, when adding a new smart meter, device type 0x05 is bound to PID=30003.

[0061] The service priority mapping table defines the execution order of different services, ensuring that critical business operations have priority in resource allocation. Priority is linked to the PriorityLevel field of the service construction list, determining the priority of container startup and traffic forwarding.

[0062] Shared memory uses memory mapping technology to map physical memory blocks to the virtual address spaces of multiple processes, enabling copy-free data sharing and direct method calls. It serves as the carrier for cross-process communication of hook functions. During hardware initialization, a shared memory segment is created using `shmget()` with read and write permissions set; a dedicated area is allocated to store hook function pointers, resource data caches, process binding rule tables, etc. The service orchestration layer and service management layer use the `mmap()` system call to map the shared memory segment to their respective virtual address spaces. After mapping, read and write operations on this address range by a process directly affect physical memory, eliminating the need for kernel-mode / user-mode data copying. The hook injection submodule uses the `Inject` injector to write server-side hook functions into the shared memory. For example, the service orchestration layer can directly execute the target method by reading the function pointer from the shared memory.

[0063] The hook function obtains resource data in real time through a resource query interface, matches service processes based on process binding rules, ensures critical business scheduling through a service priority mapping table, and finally achieves direct cross-process method invocation through a shared memory mapping mechanism. This reduces the cross-layer communication latency of traditional gateways from milliseconds to microseconds, while simultaneously improving the flexibility and reliability of service scheduling, providing core technical support for dynamic service orchestration in complex IoT scenarios.

[0064] The service management layer is responsible for resource coordination and global decision-making functions, including a resource queryer, a service controller, and a proxy communication submodule.

[0065] The resource queryer directly calls the hardware layer interface via a static method to collect resource data from the gateway and edge nodes in real time and stores it in a distributed database, providing data support for decision-making.

[0066] The resource data includes CPU utilization, memory usage, and network bandwidth.

[0067] Based on the classified message requirements and real-time resource data of the service orchestration layer, the service controller calls a dynamic programming multi-segment graph algorithm to calculate the globally optimal service deployment path. Under multiple nodes, multiple service types, and multiple resource constraints, it finds the service chain deployment scheme with the fastest response and the highest resource utilization, generates a service construction linked list, and writes it into shared memory for the service data layer to call, thus avoiding resource overload or waste.

[0068] like Figure 4 As shown, the dynamic programming multi-segment graph algorithm for calculating the globally optimal service deployment path specifically includes: Step 201: Convert the service deployment path into a directed weighted multi-segment graph.

[0069] The DirectedWeightedMultistageGraph is a special type of directed graph that includes a segmented structure, directed edges, and weight attributes, and can be represented as G=(V,E,W).

[0070] V represents the vertex set, which is divided into contiguous and non-overlapping segments according to the service execution order. Each segment corresponds to a service step, such as authentication, data encryption, and traffic forwarding. Each segment contains several vertices V=(S1,S2,...,S...). i ), S i Let be the set of vertices in the i-th segment, where each vertex represents a physical node that can be deployed for that service segment. There is a strict order between segments, and vertices within the same segment are not connected.

[0071] V0 represents the virtual starting vertex, which connects all nodes in the first segment S1 and has a weight of 0.

[0072] V i This indicates a virtual terminating vertex, formed by the last segment S. i All nodes are connected, with a weight of 0.

[0073] E represents the edge set, which contains only directed edges between adjacent vertices. The direction of the edges is fixed as the front segment points to the back segment, and there are no cross-segment or reverse edges.

[0074] W represents the weight set, where each edge is assigned a non-negative weight value, representing the deployment cost from one node to another. For example, w(v,u) represents the cost or expense of moving from vertex v to vertex u. This includes resource cost, communication cost, and reliability cost. The resource cost refers to the CPU and / or memory usage cost of the node deployment service, C. res =α × CPU utilization + β × memory utilization, where α and β are weighting coefficients. The communication cost refers to the data transmission delay between nodes, C. comm =Data volume / bandwidth. The reliability cost refers to the historical failure probability of a node, C. rel =1 - Node fault-free runtime / Total runtime.

[0075] Total weight formula: C = ω1 × C res +ω2×C comm +ω3×C rel ω1+ω2+ω3=1, and can be dynamically adjusted according to business scenarios, such as increasing the weight of ω2 in real-time scenarios.

[0076] Step 202: Use reverse dynamic programming to derive the optimal path from back to front.

[0077] Based on the segmentation-free aftereffect property of the directed weighted multi-segment graph, inverse dynamic programming is adopted. Starting from the last segment, the minimum cost from each node of each segment to the destination is calculated in turn, and finally the optimal path from the starting point to the destination is obtained by backtracking.

[0078] Specifically, first define cost[i][v], which represents the minimum total cost from vertex v in the i-th segment to the endpoint. For the last segment S... i For all vertices v, cost[i][v] = the weight of edge (v, destination Vk), which is the communication cost and resource cost from the node to the destination. From segment i-1 to segment 1, for each vertex v in segment i, calculate cost[i][v] = min(weight of edge (v,u) + cost[i+1][u]). Where u represents the vertex connected to v in segment i+1. The cost of each vertex v from the starting point V0 to segment 1 S1 is the weight of edge (V0,v) + cost[1][v]. Select the vertex corresponding to the minimum value as the starting point of the path. Starting from the optimal node in segment 1, select the vertex u that minimizes the cost in each segment in reverse order according to the calculation process of cost[i][v], until the destination V.i This forms a complete service deployment path.

[0079] Step 203: After generating the optimal path, connect it with the service building linked list.

[0080] After the algorithm generates the optimal path, each vertex corresponds to a service node in the service construction linked list, with TargetNodeIP set to the physical node IP of the vertex. The edge weight calculation results are mapped to the CPUQuota and MemoryQuota of the service node. The path priority corresponds to the PriorityLevel of the head node of the linked list.

[0081] The resulting service building linked list is written to shared memory for the service data layer to parse and start the container.

[0082] The service construction linked list is the core data carrier connecting service requirements and service execution in the dynamic service orchestration of the smart gateway. It is used to standardize the description of service deployment paths, resource mapping relationships, and execution rules. Based on the collaborative requirements of the three-layer architecture of the smart gateway, its structure adopts a hierarchical node design, supporting dynamic expansion and efficient cross-process parsing. The service construction linked list adopts a linear linked structure, including a head node, service nodes, and a tail node. Each node contains a basic attribute segment and a functional extension segment, and the association between nodes is realized through pointer fields.

[0083] As shown in Table 1, the head node stores the global information of the service construction linked list and serves as the entry point for parsing the service construction linked list.

[0084] Table 1 Head Node Structure Table

[0085] As shown in Table 2, each service node describes the deployment information of a single service (such as service type, node IP, and resource quota). There can be multiple service nodes, each corresponding to a specific service, which are connected in sequence according to the business process.

[0086] Table 2 Service Node Structure Table

[0087] As shown in Table 3, the tail node marks the end of the service construction list and contains verification information to verify the integrity of the service construction list.

[0088] Table 3 Tail Node Structure Table

[0089] The overall service build list is stored in a pre-allocated area of ​​shared memory in binary stream form. After the service management layer is generated, the nodes are linked together by the NextNodePtr pointer. The service data layer traverses all nodes sequentially by the head node pointer.

[0090] The service data layer reads the head node, confirms the number of service nodes using TotalNodes, and determines the execution priority using PriorityLevel. Then, it parses each service node sequentially using NextNodePtr, extracting TargetNodeIP and HostPort to configure container startup parameters, and configuring network forwarding rules based on ProtocolType and VLANID. Finally, when parsing the tail node, it verifies EndFlag and Checksum; if the verification fails, the service is discarded, the linked list is built, and the service management layer is requested to regenerate it.

[0091] When resource status changes, the service management layer updates the service construction chain by modifying the TargetNodeIP and ResourceQuota fields of the service nodes, and synchronously updates the checksum of the tail node. The service data layer detects the update by detecting changes in GenerateTime, thus realizing the dynamic adjustment of the service chain.

[0092] The proxy communication submodule communicates across processes with the proxy end of the service orchestration layer through the IBinder mechanism, receives classified messages and returns a memory pointer to the service construction list, thereby achieving real-time synchronization of service requirements and resource status and ensuring data interaction between layers.

[0093] The service data layer is responsible for service instantiation and traffic loop closure, including container engine and traffic forwarder.

[0094] The container engine parses the service building list in shared memory, calls the Docker API to dynamically start the corresponding IoT security service container, and configures virtual bridges and network isolation rules between containers to achieve elastic scaling of services.

[0095] Specifically, the container engine directly accesses the service building linked list in shared memory through memory mapping, parsing it in the order of head node, service node, and tail node, and verifying the integrity of the nodes. It reads the EndFlag of the tail node to confirm the linked list's integrity and uses a Checksum to verify whether the data has been tampered with; if the verification fails, it sends an invalid linked list signal to the service management layer, requesting a re-access. It parses the LinkVersion of the head node to match the local parser version and uses PriorityLevel to determine the deployment priority, with higher-priority services building linked lists receiving priority resource allocation.

[0096] Extract the service node parameters and convert them into key-value pairs that the Docker API can recognize, as shown in Table 4. Then, combine the extracted service node parameters into Docker API call instructions.

[0097] Table 4 shows the key-value pairs that the service nodes can be converted into and recognized by the Docker API.

[0098] The traffic forwarder issues flow tables based on the OpenFlow protocol. According to the process identifier of the classified message and the port mapping relationship of the service building list, it directs the traffic to the corresponding service container. The processed traffic is forwarded to the cloud platform or local device through the network interface module, forming a closed loop of device traffic, service processing and traffic forwarding.

[0099] The cross-layer collaborative unit ensures the stable operation of the system and includes a fault self-healing module and a mode switching module.

[0100] The fault self-healing module monitors the running status of the service container in real time. When an abnormality is detected in the service container, it re-injects the resource scheduling process of the service management layer through the Hook function, calls the service backup on the server to build the linked list and other operations, restarts the container on the backup hardware resources, and reconfigures the traffic forwarding rules to quickly restore the service and avoid service interruption.

[0101] Fault classification includes P0, P1, P2, and P3. P0 is a fatal fault, including main CPU failure and local database corruption, affecting all services and requiring immediate active-active failover. P1 is a severe fault, including continuous restarts of core service containers and complete outages of 4G / 5G modules, affecting critical services, with a recovery time requirement of <3 seconds. P2 is a general fault, including non-core container anomalies and single-link interruptions at edge nodes, affecting localized functions, with a recovery time requirement of <10 seconds. P3 is a minor fault, including individual flow table delivery failures and single-time memory ECC error correction, with no significant impact and can be handled with a delay.

[0102] For different levels of failure, a tiered approach is adopted, first restoring services and then repairing the root cause, to ensure that business continuity is prioritized.

[0103] The mode switching module supports flexible switching between local autonomy and cloud collaboration modes, ensuring normal scheduling of local services during network outages and data synchronization after network recovery, thus guaranteeing system continuity in complex network environments.

[0104] Specifically, under normal circumstances, distributed centralized management and control are achieved through a cloud platform, enabling real-time status synchronization. The mode switching module establishes a long connection with the cloud platform through a hardware layer network interface, sending heartbeat packets at regular intervals to synchronize the core gateway status, including the version number of the currently active service building list, container running status, hardware resource utilization, and device traffic classification statistics.

[0105] The cloud platform updates the global scheduling view based on the reported data. If the service deployment path needs to be adjusted, the service management layer sends an instruction through the proxy communication submodule. The service management layer then regenerates the service building list and synchronizes it to the shared memory.

[0106] Every 30 minutes, the service management layer backs up the latest service build list, device communication logs, and service scheduling rule data to the hardware layer storage module. The mode switching module verifies the integrity of the backup data; if the backup fails, it triggers a local alarm and notifies the service management layer to re-execute the backup.

[0107] When the network is paralyzed or disconnected, the local database and SSD cache are automatically activated for service scheduling; after the network is restored, the local data is synchronized to the cloud via the 4G / 5G module to ensure that the local data is consistent with the cloud data.

[0108] The mode switching module monitors network connectivity in real time. When no response is received from the cloud platform after three consecutive heartbeats, the local autonomous mode is immediately triggered, and a mode switching signal is sent to the cross-layer collaborative unit. The service management layer suspends communication with the cloud platform, and the service data layer automatically switches to reading the service building list in the SSD cache.

[0109] The container engine parses the locally cached service build list, calls the Docker API to start local service containers, and configures virtual bridges and network isolation rules. The traffic forwarder distributes local flow tables based on the OpenFlow protocol, directing device traffic to the corresponding service containers according to the process identifiers of categorized packets and their mapping to local ports. The fault self-healing module runs independently, monitoring the status of local containers. If a container anomaly is detected, it directly reads the locally backed-up service build list, restarts the container on backup hardware resources, and reconfigures the traffic rules.

[0110] Device logs and service scheduling records generated during network outages are written to the local database in real time; SSDs cache frequently accessed service chain rules to ensure that the local service response speed is no slower than that of the cloud-based collaborative mode.

[0111] After the network is restored, the mode switching module detects that the network has been restored and first sends test data packets to the cloud platform through the 4G / 5G module to verify connectivity and transmission stability. After five consecutive successful transmissions of test data packets, the network is determined to have been restored to normal and the data synchronization process is initiated.

[0112] By comparing the last synchronization timestamps of the local database and the cloud database, incremental data during the network outage period is extracted, including device logs, service scheduling records, and service build list updates. Core business data is synchronized first via the 4G / 5G module, followed by ordinary log data. An incremental verification mechanism is used during the synchronization process to avoid duplicate data. If there is a version conflict between the local and cloud platform's service build lists, the latest version on the cloud platform is used as the benchmark, and combined with the local service running status, the service management layer regenerates a compatible service build list and synchronizes it to shared memory and the cloud.

[0113] After data synchronization is complete, the mode switching module reports the local service status to the cloud platform and requests a switchback to the cloud collaborative mode. Once the cloud platform confirms data consistency, it issues a switchback command, the service management layer resumes real-time communication with the cloud platform, and the mode switching module resumes its heartbeat synchronization mechanism. The cross-layer collaborative unit verifies that all container operations, traffic forwarding, and resource scheduling are normal before completing the mode switchback.

[0114] By using Hook technology to monitor and verify the program execution flow, combined with hardware-level detection or recovery mechanisms, abnormal jumps of the program counter (PC) pointer, false interrupt triggering, or illegal instruction execution caused by lightning strikes or electromagnetic pulses (EMP) can be prevented, ensuring the safe and stable operation of the smart gateway in environments with strong electromagnetic interference.

[0115] The following is a description with reference to specific embodiments: Example 1: By using compile-time instrumentation hooks and runtime register verification, it effectively prevents strong interference such as lightning strikes and electromagnetic pulses (EMPs) from disrupting the program flow, causing the PC pointer to skip security checks and directly execute high-risk actions.

[0116] By using compile-time instrumentation, a signature of the legal call path for critical functions is generated. At runtime, this signature is bound to a dedicated hardware register. A multi-round redundant verification mechanism is used to verify the legality of the call to critical functions, identify and intercept illegal execution processes that bypass security checks, and trigger security traps to achieve fault isolation and data retention.

[0117] Specifically, the control flow graph (CFG) of the source code is analyzed during the compilation phase using LLVM Pass or the GCC plugin. Key function nodes, such as Open_Valve(), are identified, and the path signatures of all its valid predecessor nodes (Predecessors) are calculated. A globally dedicated CPU register, such as the R9 register in the ARM architecture, is defined solely for storing path hashes and is prohibited from use by regular logic.

[0118] At the end of all preceding functions that legally call Open_Valve(), the assembly instruction MOV R9,#0xA1B2 is injected, writing a valid path signature into R9. Therefore, R9 will only contain the correct value after the flow has gone through a normal logical jump.

[0119] At the entry point of the `Open_Valve()` function, insert a trampoline hook or directly inline assembly verification logic. First, compare the current value of R9 with the expected signature: `CMP R9, #0xA1B2`. If the current value of R9 is not equal to the expected value, it indicates that it was dropped from an illegal path, and jump to the exception trap: `BNE.EMP_Trap_Handler`. If the verification passes, immediately clear R9 to prevent the signature from being misused by subsequent functions: `EOR R9,R9,R9`.

[0120] To prevent EMP from accidentally reversing the execution result of the CMP instruction itself, the Hook logic is executed three times: CMP R9, #0xA1B2; BEQ .Next1; B .Trap; .Next1: CMP R9, #0xA1B2; BEQ .Next2; B .Trap; .Next2: CMP R9, #0xA1B2; BNE .Trap. A two-out-of-two decision mechanism is used to ensure the atomicity and unbypassability of the verification logic itself. If all three verification results are consistent, the control flow is considered valid; otherwise, the control flow is considered invalid.

[0121] Upon entering .EMP_Trap_Handler, all interrupts are immediately disabled to prevent cascading errors. The GPIO output registers are forced to all zeros or a specific safety level, and the current PC pointer value is recorded to non-volatile memory for later analysis of the code location at the moment of the lightning strike.

[0122] This embodiment uses a dedicated register to bind path signatures to identify abnormal PC pointer jumps caused by EMP, with a false positive rate of 0; the triple redundancy check mechanism improves the fault tolerance of the check logic for single-event flips; and the retained PC pointer data provides technical support for the root cause analysis of electromagnetic interference events.

[0123] Example 2: By hijacking the interrupt vector table and fusing ADC multi-mode signals, the EMP can effectively prevent false high levels from being sensed on the signal lines, thus preventing false interrupt triggering.

[0124] During system startup, the interrupt vector table is copied from Flash to RAM, and the interrupt service routine address for critical GPIOs is modified to point to the Proxy_Hook_Handler entry point. When a critical GPIO interrupt is triggered, the hook program first saves the context, then starts the high-priority ADC channel to read the voltage value V from the electromagnetic coil sensor on the PCB. emp When V emp If the signal duration exceeds the preset threshold and is short, it is determined to be a phantom interrupt caused by EMP. The interrupt flag is cleared and the global EMP storm mode is set. The software timer is enabled to block unnecessary external interrupts. When the electromagnetic environment is normal, the original interrupt service routine address is retrieved from the lookup table and the normal business logic is executed.

[0125] Specifically, during system startup, the interrupt vector table is copied from Flash to RAM for modification. The interrupt service routine address for critical GPIO pins is located, such as EXTI_Line0 corresponding to the emergency stop button. This address is then modified to point to the entry address of the Proxy_Hook_Handler.

[0126] When lightning strikes and triggers EXTI_Line0, the CPU jumps to Proxy_Hook_Handler. Hook first executes PUSH(R0-R3,LR) to save the context. Hook immediately starts the high-priority ADC channel and reads the voltage value V from the electromagnetic coil sensor connected to the PCB. emp .

[0127] Hook reads the current system clock T now When V emp > V threshold This indicates that the current electromagnetic environment is extremely harsh. Furthermore, the signal duration T... signal When the time is less than 50ms, the signal is extremely short, indicating that it conforms to pulse characteristics. At this time, the signal is a phantom interrupt caused by EMP. The Hook writes a Clear Pending instruction to the interrupt controller to clear the interrupt flag, pretending nothing happened. The global flag System_State is set to EMP_STORM_MODE. A 200ms software timer is started, during which all unnecessary external interrupts are disabled. The Hook executes POP(R0-R3, PC) and returns immediately, without executing the original business logic.

[0128] If V is determined emp Under normal conditions with no lightning interference, the Hook retrieves the address of the Original Interrupt Service Routine (ISR) from the lookup table. It then jumps to the original ISR via a BX instruction to ensure that normal operations are unaffected.

[0129] Example 3: By modifying the Linker Script Hacking and rewriting exception handling in the linker script, EMP can effectively prevent the PC pointer from flying around erratically, executing illegal instructions, or tampering with data.

[0130] Modify the linker script to define all unused Flash and RAM space as the .honeypot segment, and fill this segment with trap instructions during the compilation and linking phase. Rewrite the CPU's HardFault_Handler hardware error handling and UsageFault_Handler error handling functions, and read the trigger address saved in the stack frame at the function entry point; when the trigger address falls within the .honeypot segment range, it is determined to be an abnormal PC pointer jump caused by EMP, without performing a system reboot operation, directly reading the upper safe checkpoint from FRAM / MRAM, forcibly restoring the CPU register state to the safe checkpoint, and executing the exception return instruction.

[0131] Specifically, the linker script is modified to define all unused Flash and RAM space as a section named `.honeypot`. During the compilation and linking phase, the Fill Command is used to fill this section entirely with specific trap instructions. For ARM architecture, 0xDE00 (UDF instruction, triggering a UsageFault) or 0xF7F0A000 jump instruction is filled in. For RISC-V architecture, 0x00000000 illegal instruction exception is filled in. The final memory map shows that, apart from the normal code and data areas, the rest is entirely filled with traps.

[0132] Rewrite the CPU's HardFault_Handler hardware error handling and UsageFault_Handler. At the Handler entry point, hook the return address stored in the stack frame, which is the address of the instruction that triggered the exception.

[0133] The hook checks if the returned address falls within the address range defined by `.honeypot`. If so, it confirms that an EMP caused the PC pointer to jump to a blank area. If not, it's likely a regular code bug, and the process proceeds to the standard error handling flow.

[0134] The hook does not perform a reboot because a reboot takes several seconds and could cause the system to malfunction. Instead, the hook reads the previous safe checkpoint from the FRAM / MRAM. This safe checkpoint contains key variable values, the state machine state ID, and a valid PC pointer position. The hook then forces the CPU registers to be restored to the values ​​from the safe checkpoint.

[0135] The Hook executes the exception return instruction, and the CPU continues execution from the previous safe state. The entire process is completed in less than 50 microseconds, achieving microsecond-level self-healing.

[0136] In this embodiment of the invention, V is introduced. emp As the basis for logical judgment, TMR triple redundancy and TrapInstruction padding are adopted to specifically combat the bit-flip of the physical layer. Integrated into the cross-layer collaborative unit of the smart gateway, it works in conjunction with the dynamic service scheduling device to achieve microsecond-level response through ISR Hook and Checkpoint Restore, meeting the timeliness requirements of lightning protection. While ensuring electromagnetic interference protection, it does not affect the real-time service scheduling capability of the gateway, which is completely different from the existing general software anomaly handling.

[0137] This invention discloses a dynamic service scheduling device and method for a smart gateway. Firstly, the software layer employs a three-layer architecture to achieve functional decoupling, allowing each layer to dynamically adjust services according to actual needs. The service orchestration layer generates differentiated service chains based on device traffic characteristics, and the service data layer dynamically starts or stops service containers to meet the personalized service needs of different IoT devices, enhancing the gateway's flexibility and adaptability. Secondly, through Hook function injection and shared memory technology, direct cross-process method calls are achieved without relying on complex communication protocols, reducing protocol encapsulation and parsing during data transmission, significantly lowering cross-layer communication latency, and meeting the real-time requirements of IoT scenarios. Furthermore, the fault-healing unit of the cross-layer collaborative unit can quickly restore services when service containers malfunction, avoiding service interruptions; the dual-active switching unit supports flexible switching between local and cloud modes, ensuring that the gateway can still operate normally and prevent data loss even in extreme situations such as network interruptions, improving the reliability and stability of the IoT system. Finally, the service management layer collects resource data in real time and calls dynamic programming algorithms to generate the optimal service deployment path, avoiding resource waste, ensuring efficient utilization of hardware resources, and reducing the operating costs of the IoT system.

[0138] The above description illustrates preferred embodiments of the present invention and helps those skilled in the art to more fully understand the technical solution of the present invention. However, these embodiments are merely illustrative and should not be construed as limiting the specific implementation of the present invention to these embodiments. For those skilled in the art, several simple deductions and modifications can be made without departing from the inventive concept, and all such modifications should be considered within the protection scope of the present invention.

Claims

1. A dynamic service scheduling device for an intelligent gateway, characterized in that, It includes a hardware layer, a software layer, and cross-layer collaboration units. The software layer includes a three-layer architecture: a service orchestration layer, a service management layer, and a service data layer. The service orchestration layer performs layered parsing of service requirements and process binding, and completes the classification of device traffic and preparation for cross-process method calls; The service management layer acquires resource data and plans the optimal service deployment path, generates a service construction list, and stores it in shared memory. The service data layer completes the startup of service containers and the targeted forwarding of traffic, forming a dynamic service chain closed loop, enabling dynamic scheduling and on-demand deployment of IoT device services.

2. The dynamic service scheduling device for an intelligent gateway according to claim 1, characterized in that, The service orchestration layer includes a traffic classifier and a Hook injection submodule; The traffic classifier analyzes the uplink traffic of IoT devices using deep packet inspection technology, generates classified messages according to multiple dimensions and carries process identifiers; The Hook injection submodule injects the Hook function containing the server into the resource scheduling process of the service management layer through the Inject injector, registers the scheduling methods required for resource scheduling into shared memory, and builds a bridge for cross-process calls between the service orchestration layer and the service management layer.

3. The dynamic service scheduling device for an intelligent gateway according to claim 2, characterized in that, Based on the deep packet inspection results, classified messages are generated according to four dimensions: device attributes, protocol type, data characteristics, and business scenarios. The classified messages adopt a structure of fixed header, variable label, and raw data, which not only contains multi-dimensional classification results but also carries service process identifiers.

4. The dynamic service scheduling device for an intelligent gateway according to claim 2, characterized in that, The Hook function includes a resource query interface, process binding rules, and a service priority mapping table, and enables direct cross-process method invocation through a shared memory mapping mechanism.

5. The dynamic service scheduling device for an intelligent gateway according to claim 1, characterized in that, The service management layer includes a resource queryer, a service controller, and a proxy communication submodule. The resource queryer directly calls the hardware layer interface to collect resource data from the gateway and edge nodes in real time and stores it in a distributed database. The service controller, based on the classified message requirements and real-time resource data, calls a dynamic programming multi-segment graph algorithm to calculate the globally optimal service deployment path, generates a service construction linked list, and writes it into shared memory; The proxy communication submodule communicates with the proxy through the IBinder mechanism, receives classified messages and returns a memory pointer to the service construction linked list.

6. The dynamic service scheduling device for an intelligent gateway according to claim 5, characterized in that, The dynamic programming multi-segment graph algorithm specifically includes: Step 201: Construct a multi-segment graph model to transform the service deployment path into a directed weighted multi-segment graph; Step 202: Use reverse dynamic programming to derive the optimal path from back to front; Step 203: After generating the optimal path, connect it with the service building linked list.

7. The dynamic service scheduling device for an intelligent gateway according to claim 5, characterized in that, The service building linked list adopts a linear linked structure and is stored in shared memory in binary form. It includes a head node, service nodes, and a tail node. Each node contains a basic attribute segment and a functional extension segment. The association between nodes is realized through pointer fields.

8. The dynamic service scheduling device for a smart gateway according to claim 1, characterized in that, The service data layer includes container engines and traffic forwarders; The container engine parses the service building list in shared memory, calls the Docker API to dynamically start the corresponding IoT security service container, and configures virtual bridges and network isolation rules between containers. The traffic forwarder issues flow tables based on the OpenFlow protocol and directs traffic to the corresponding service container according to the process identifier of the classified packets and the port mapping relationship of the service building linked list.

9. The dynamic service scheduling device for a smart gateway according to claim 1, characterized in that, The cross-layer collaborative unit includes a fault self-healing module and a mode switching module; The fault self-healing module monitors the running status of the service container in real time. When an abnormality is detected in the service container, it re-injects the resource scheduling process of the service management layer through the Hook function, calls the service building linked list operation of the server backup, restarts the container on the backup hardware resources, and reconfigures the traffic forwarding rules. The mode switching module supports flexible switching between local autonomy and cloud collaboration modes, ensuring normal scheduling of local services during network outages and data synchronization after network recovery, thus guaranteeing system continuity in complex network environments.

10. The dynamic service scheduling device for a smart gateway according to claim 1, characterized in that, The hardware layer includes a network interface module, which includes an Ethernet port, Wi-Fi, TCP, and 4G / 5G full network compatibility.

11. A dynamic service scheduling method for intelligent gateways, applicable to dynamic service scheduling devices for intelligent gateways, characterized in that, Specifically, it includes: Step 1: The service orchestration layer performs service requirement layering and process binding, completing the classification of device traffic and preparation for cross-process method calls; Step 2: The service management layer acquires resource data and plans the optimal service deployment path, generates a service construction linked list, and stores it in shared memory; Step 3: The service data layer completes the startup of the service container and the targeted forwarding of traffic, forming a dynamic service chain closed loop, realizing the dynamic scheduling and on-demand deployment of IoT device services.

Images