Distributed real-time embedded control system based on service-transport decoupling

Abstract

The application discloses a kind of based on service-transmission decoupling distributed real-time embedded control system, belongs to distributed real-time embedded control technical field.The system includes configuration module, transmission service module, service logic module, core service encapsulation module and log storage module.Transmission service module is uniformly managed subject data reception and service processing function distribution by subscribing registry and independent data polling thread;Service processing function only calls core service encapsulation module and log storage module.When new service is added, only data structure definition, subject configuration, callback implementation and registration binding need to be completed, without modifying the internal logic of transmission service module.The application is conducive to improving system expansibility, maintainability, thread safety and monitoring convenience.

Description

Technical Field

[0001] This application relates to the field of spacecraft ground telemetry and control technology, and in particular to a distributed real-time embedded control system based on service-transmission decoupling. Background Technology

[0002] In distributed real-time embedded systems such as spacecraft ground telemetry and control, unmanned swarm control, and industrial automation, DDS is widely used for data interaction between multiple nodes due to its high throughput, low latency, and configurable Quality of Service (QoS).

[0003] However, traditional DDS development models typically couple data transmission and reception, data serialization and deserialization, and specific business logic, such as instruction parsing, algorithm calls, and data storage, into a single module. This model usually suffers from the following problems.

[0004] First, it has poor scalability. Each new data interaction type usually requires simultaneous modifications to multiple parts of the code, including DDS entity creation, data reception and processing, business calls, and logging. Developers need to understand the existing business logic and transmission details, which can easily lead to regression issues.

[0005] Second, it is difficult to maintain. Changes in transport layer configuration may affect core business processing; the same source file contains both DDS interface calls and business algorithm code, which is not conducive to the division of responsibilities and modular maintenance.

[0006] Third, reusability is low. Business logic is often deeply bound to a specific DDS implementation, and a lot of adaptation work is required when migrating to other message middleware or reusing it in other ground systems.

[0007] Fourth, testing is complex. Unit testing of business modules usually relies on a real DDS network environment, making it difficult to flexibly simulate faults, inject abnormal data, or independently verify business processing logic; in a multi-threaded environment, the concurrent competition between the DDS receiving thread and the business processing thread may also introduce hidden defects.

[0008] In existing technologies, some solutions have attempted to address related issues. For example, Chinese invention patent CN110324325A proposes a "configuration-driven dynamic loading method for satellite communication protocols." This method describes communication protocol fields using a JSON-formatted configuration file. The software parses the configuration file and dynamically constructs the protocol processing logic at runtime, thus decoupling the communication protocol from the software code. However, this decoupling is limited to the protocol layer; the business logic and transmission module remain in the same process space. Adding new business data still requires modifying the protocol parsing code and reconfiguring, failing to achieve "plug-and-play" functionality.

[0009] The paper "Design of Satellite Multi-Target Measurement and Control System Based on DDS" published in the Proceedings of the 18th Annual Conference on Satellite Communications (2022) adopts the publish / subscribe model of DDS to build the system. However, the paper only stays at the level of the overall application architecture of DDS and does not explore in depth how to separate the transport layer from specific service callbacks, nor does it provide a general service extension mechanism.

[0010] Chinese invention patent with publication number CN117518876A discloses a control and management system that supports heterogeneous interconnection between digital and physical satellite simulation models. It uses DDS to solve the problem of heterogeneous interconnection between digital and physical models. Its core is data standardization and model integration, rather than decoupling business logic and transmission mechanisms at the software architecture level.

[0011] However, the above solutions usually focus on dynamic protocol loading, overall data distribution architecture, or model integration, and have not formed a system architecture that can completely separate the transport layer from specific business processing functions and support plug-and-play extension through a unified registration mechanism when adding new business topics.

[0012] Furthermore, in conventional designs in this field, callback functions are typically designed to directly carry relatively complete business processing logic to reduce the call layers between modules and pursue local processing efficiency. While this design approach offers a degree of flexibility, it also blurs the boundary between the transport layer and the business layer. When adding new services, it is often necessary to understand the communication details, thus limiting further improvements in system scalability and maintainability.

[0013] Therefore, it is still necessary to provide a new distributed real-time embedded control system and its business extension method, so as to achieve a clear separation between business logic and transport layer while retaining the real-time communication capability of DDS, and to support adding new business functions with minimal modification to existing module code. Summary of the Invention

[0014] To address the problems existing in the prior art, the purpose of this application is to provide a distributed real-time embedded control system based on service-transmission decoupling, in order to solve the problems of tight coupling between business logic and communication transmission layer, many modification points when expanding new services, high testing and maintenance costs, and insufficient thread safety guarantee under multi-threaded conditions in the prior art.

[0015] To achieve the above-mentioned objectives, this application provides a distributed real-time embedded control system based on service-transmission decoupling, comprising the following steps:

[0016] The configuration module is used to store system operating parameters, which include at least the system identifier, topic path, middleware domain identifier, core business library path, and log capacity.

[0017] The transmission service module manages the lifecycle of the data distribution middleware and provides subscription registration, publication registration, and data sending and receiving services.

[0018] The business logic module is used to register the business processing functions corresponding to each business theme to the transmission service module, and call the transmission service module to publish business data;

[0019] The core business encapsulation module is used to encapsulate the core business library and provide business processing interfaces to the outside world;

[0020] The log storage module is used to record business processing logs and exception logs;

[0021] in,

[0022] The transmission service module includes a subscription registry and an independently running data polling thread;

[0023] The subscription registry is used to store the mapping relationship between topic paths, data readers corresponding to topic paths, and business processing functions.

[0024] The data polling thread is used to traverse the registered data readers at fixed intervals, call the data acquisition interface of the data reader to obtain data samples, and find and execute the corresponding business processing function according to the subscription registry.

[0025] The business processing function is used to receive the data sample and only performs the following operations: calling the business processing interface provided by the core business encapsulation module and calling the log storage module to record logs;

[0026] When a new business topic is added, the data structure definition, topic configuration, business processing function writing, and registration binding of the new business topic only need to be completed in the business logic module, without modifying the internal processing logic of the transmission service module.

[0027] According to one technical solution of this application, the transmission service module further includes a registry publishing system and a unified registration interface.

[0028] The publishing registry is used to maintain the mapping between topic paths and data writers.

[0029] The unified registration interface includes at least a subscription registration interface and a publish registration interface.

[0030] The subscription registration interface is used to associate and register topic paths, data types, data readers, and business processing functions, while the publication registration interface is used to associate and register topic paths, data types, and data writers.

[0031] According to one technical solution of this application, the data polling thread captures exceptions when executing the business processing function and writes the exception information to the log storage module to prevent the data polling thread from exiting due to the failure of a single business processing function.

[0032] According to one technical solution of this application, the business logic module further includes an independent timed task thread, which calls the core business encapsulation module to obtain business results according to a preset period, and publishes the business results through the unified publishing interface provided by the transmission service module.

[0033] According to one technical solution of this application, the configuration module is used to generate or store the paths of each topic according to a unified naming convention, wherein the unified naming convention is:

[0034] / {SystemID} / {ServiceType} / {APID} / {InterfaceType} / {TopicFunction};

[0035] Both the transmission service module and the business logic module operate based on the parameters provided by the configuration module to achieve configuration-driven system behavior.

[0036] According to one technical solution of this application, the core business encapsulation module is used to load the core business library through dynamic linking;

[0037] When the core business library fails to load, the core business encapsulation module sets its own state to unavailable and records an error log, while the transmission service module, business logic module and log storage module continue to run.

[0038] The core business encapsulation module also provides a status query interface to expose the current availability status.

[0039] According to one technical solution of this application, the core business encapsulation module is equipped with a mutex lock to provide concurrent protection for core business library calls initiated by multiple threads, so as to ensure thread safety when data reception and processing and timed task processing are executed concurrently.

[0040] According to one technical solution of this application, the log storage module adopts a two-layer storage structure combining a memory circular queue and disk files;

[0041] The log storage module also provides a log retrieval interface based on identifier increment, which allows the monitoring module to poll for newly added logs and display them in real time.

[0042] According to one aspect of this application, a service extension method for a distributed real-time embedded control system based on service-transmission decoupling as described in any of the above technical solutions is proposed, comprising the following steps:

[0043] Step S1: Define the data structure corresponding to the newly added business topic to meet the system's preset data serialization requirements;

[0044] Step S2: Add the topic path corresponding to the newly added business topic in the configuration module;

[0045] Step S3: Write a business processing function corresponding to the newly added business topic in the business logic module. The business processing function only executes the business processing interface provided by the core business encapsulation module and the log storage module to record logs.

[0046] Step S4: During system initialization, the newly added business topic, the corresponding data reader, and the business processing function are bound and registered through the subscription registration interface of the transmission service module.

[0047] After completing steps S1 to S4, the data polling thread of the transmission service module automatically receives the data of the newly added business topic and calls the corresponding business processing function without modifying the code of the transmission service module, log storage module and monitoring module.

[0048] According to one technical solution of this application, the distributed real-time embedded control system is applied to a spacecraft ground telemetry and control system, a UAV ground station system, an industrial robot control system, an autonomous driving data distribution system, or an edge computing node control system, and supports cross-platform deployment and adaptation and replacement between different message middleware.

[0049] Compared with existing technologies, the distributed real-time embedded control system based on service-transmission decoupling provided in this application has the following significant technical advantages:

[0050] Through the collaborative design of a subscription registry, a unified registration interface, and an independent data polling thread, the transport layer can uniformly manage data readers and business processing functions corresponding to different business themes. This allows for the support of new business themes without changing the internal processing logic of the transport layer, thereby improving the system's scalability.

[0051] By defining the responsibilities of business processing functions, these functions are primarily responsible for "calling core business encapsulation modules" and "logging," reducing the direct dependence of business logic on DDS details. This helps to clarify the boundary between the business layer and the transport layer and reduces the burden on business developers to understand the underlying communication implementation.

[0052] By capturing exceptions in the execution of business processing functions in the data polling thread, the impact of a single business processing exception on the overall data receiving process can be reduced, thereby improving the stability of system operation.

[0053] By using core business encapsulation modules to dynamically load the underlying algorithm library and setting mutex locks in multi-threaded call scenarios, the concurrency safety of core business library calls can be improved, and non-dependent functions can be retained when the underlying library is abnormal or missing, thus enhancing system fault tolerance.

[0054] The log storage structure combines a memory circular queue with disk files and provides an incremental pull interface, which can balance log writing efficiency, historical persistence capability and real-time monitoring display.

[0055] Since the business layer does not directly depend on the specific DDS interface, when the message middleware needs to be replaced, the adaptation can be mainly carried out at the level of the transport service module, with less modification to the business code, thereby improving the convenience of system cross-platform and cross-middleware migration.

[0056] This application is applicable to lightweight deployment scenarios for spacecraft ground telemetry and control, UAV swarm control, industrial robot collaboration, autonomous driving data fusion, and edge computing nodes. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0058] Figure 1 This is a module-layered architecture diagram of the distributed real-time embedded control system based on service-transmission decoupling in this application;

[0059] Figure 2 An expanded flowchart for the new business topic added to this application. Detailed Implementation

[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0061] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this application can be combined with each other. The following embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the patent application. It should be pointed out that, for those skilled in the art, several modifications and improvements can be made without departing from the concept of this application, and these all fall within the protection scope of this application.

[0062] Example 1: System Overall Architecture Implementation

[0063] like Figure 1 As shown, this embodiment provides a distributed real-time embedded control system based on service-transmission decoupling. The system includes a configuration layer, a transmission service layer, a business logic layer, a core business encapsulation layer, and a message storage and monitoring layer. To maintain consistency with the names in the claims, the "message storage and monitoring layer" in this embodiment may specifically include a log storage module and a monitoring module.

[0064] The configuration module centrally manages variable parameters, including system identifiers, topic path strings, middleware domain IDs, core business library paths, log capacity, and business result reporting intervals. The configuration module can be implemented using configuration files, constant definition files, or equivalent parameter storage methods. The transport service layer and business logic layer read these parameters during initialization to create DDS entities, establish topic path mappings, and control task cycles. The configuration module supports dynamic parameter loading at runtime or a restart-based mechanism, allowing system behavior to be adjusted solely by modifying constant files without altering other modules.

[0065] The DDS Service Module manages the lifecycle of the DDS middleware but does not handle specific business algorithms. Internally, it includes a subscription registry, a publishing registry, a unified registration interface, and an independent background polling thread. The subscription registry records the binding relationships between topic paths, data readers, and business processing functions; the publishing registry records the mapping between topic paths and data writers. The subscription registry specifically maintains the mapping between topic names and their corresponding data readers and callback functions, while the unified registration interface is used to register new subscription and publishing topics. The background polling thread iterates through registered data readers at a preset period, calls the data acquisition interface to read data samples, and then searches for the corresponding business processing function based on the subscription registry before executing it synchronously. If an exception occurs during the execution of a business processing function, the polling thread captures the exception and writes it to the error log before continuing to process other topic data.

[0066] In addition, the transport service layer provides a unified publish interface to the outside world. Business logic modules publish data through this interface without having to directly manipulate the publishing entity of the underlying middleware, thereby achieving abstraction and shielding of the transport middleware.

[0067] The business logic layer (Main & Callbacks) is used to bind specific topics with business processing functions in the system's main entry point and organize periodic business sending tasks. The business processing functions only receive data samples from the transport service layer, then call the corresponding interfaces in the core business encapsulation layer to complete the business processing, and simultaneously call the log storage module to record business logs. These business processing functions themselves do not directly manipulate DDS publish and subscribe entities, nor do they handle complex middleware configuration logic. The responsibilities of the business processing functions are strictly limited to executing core business library calls and logging operations. The business logic layer may also include independent scheduled task threads to periodically read the processing results from the core business encapsulation module and publish them externally through a unified publishing interface.

[0068] The core business encapsulation layer (Plan Module) encapsulates underlying algorithm libraries, such as planning libraries, control algorithm libraries, or other business computation libraries. These underlying algorithm libraries can be dynamic link library files (.dll or .so files). Upon system startup, this module attempts to load the dynamic library according to the configured path. If loading is successful, it provides relevant business processing interfaces and status query interfaces. If loading fails, it sets the available status to unavailable and logs an error. When a dynamic library fails to load, the core business encapsulation module exposes its current availability through the status interface, while other system modules continue to operate normally. To avoid resource contention caused by concurrent calls to the core business library by the data receiving thread and the timed publishing thread, this module uses mutex locks to protect critical interfaces.

[0069] The MessageStore & Web Module includes log storage and web monitoring functions. The log storage function uses a combination of in-memory circular queues and disk files to store business processing logs and exception logs. This two-tiered storage structure supports high-concurrency writes and provides a non-blocking log retrieval interface based on incremental IDs. The web monitoring function retrieves newly added logs through the incremental log retrieval interface and reads the status information exposed by the transport service layer and the core business encapsulation layer, displaying the system's operating status externally.

[0070] By dividing the configuration, transmission, business, core algorithms, and log monitoring into layers, the responsibilities of each module become clearer. The transmission service layer focuses on data reception, distribution, and publishing entity management; the business logic layer focuses on callback organization and business binding; the core business encapsulation layer focuses on algorithm capabilities; and the log storage and monitoring section focuses on runtime recording and visualization. This layered structure helps reduce the scope of cross-layer modifications, especially when adding new business topics. Developers typically do not need to modify the polling logic and log storage structure within the transmission service layer, thereby reducing system maintenance costs. Furthermore, with the responsibilities of callback functions constrained, the direct dependency of business logic on DDS details is reduced, facilitating independent testing of callback processing behavior and making it easier to adapt DDS to other message brokers primarily within the transmission service layer.

[0071] Example 2: Implementation of Satellite Ground Control System

[0072] This embodiment uses a satellite ground control system as an example to illustrate the specific application of this application. The system runs on a Linux or Windows platform and is responsible for receiving uplink remote control commands from the ground station and downlink telemetry data from the satellite, including GNSS status and satellite time synchronization information. It then calls the planning library to generate planning results and publishes them to other ground subsystems via DDS.

[0073] During the initialization phase, the system first reads parameters from the configuration file, such as: satellite identifier SAT_ID="SAT001", DDS domain ID is 0, planning library path is . / Plan.so, result reporting interval is 16 seconds, and log queue capacity is 500 entries. All topic path strings follow a unified naming convention: / {SystemID} / {ServiceType} / {APID} / {InterfaceType} / {TopicFunction}. The configuration module can dynamically generate topic path constants based on this convention, supporting multi-instance deployment and cross-platform compatibility. Afterwards, instances of the transport service module, core business encapsulation module, and log storage module are created. The core business encapsulation module loads the dynamic library according to the planning library path; if the dynamic library loading fails, the availability flag is set to unavailable and a warning or error log is recorded. However, the system continues to start the transport service module, log storage module, and monitoring module to retain data reception, status viewing, and log recording capabilities.

[0074] Subsequently, the business logic module binds each subscription topic to its corresponding business processing function by making multiple calls to the subscription registration interface; then, it calls the publish registration interface to complete the registration of topics that need to be sent externally. After registration is complete, the transmission service module starts a background polling thread to monitor the service startup and entry into the running state.

[0075] During the runtime phase, an external system sends a remote control command. The DDS middleware writes this command data into the data reader associated with the corresponding topic. The polling thread of the transport service layer accesses this data reader during its polling round, obtains the command data information object through the data acquisition interface, and locates the business processing function bound to the topic based on the subscription registry. Upon receiving the command data, the business processing function calls the command processing interface in the core business encapsulation module, passing the command byte stream to the underlying planning library or control algorithm library for processing. Simultaneously, it calls the log storage module to record the topic, time, processing result, or exception information of this processing. Meanwhile, an independent result reporting thread calls the result acquisition interface of the core business encapsulation module every 16 seconds. If the current planning library is available, it reads the planning result, constructs a result data object, and publishes the corresponding planning result topic externally through the unified publishing interface.

[0076] The web monitoring interface retrieves new logs by polling the incremental log retrieval interface (such as an Ajax polling interface) through the monitoring module and displays them on the monitoring page. At the same time, the monitoring module can also periodically request system status, including DDS running status, send / receive count, planning library availability flag, and system uptime, to help maintenance personnel observe the current operating status.

[0077] In satellite ground control scenarios, the system needs to continuously process uplink commands from external systems and stably output planning results or other business results, requiring high real-time performance, stability, and maintainability. Through the architecture of this application, DDS communication entity creation, data reception, and distribution are converged at the transmission service layer, while the business logic layer accesses the planning library through predefined interfaces, without directly embedding DDS implementation details. Therefore, changes to the satellite mission model, addition of topics, or replacement of the planning library version have a smaller impact. Furthermore, when the core business library fails to load dynamically, the system retains logs and monitoring capabilities, facilitating troubleshooting and deployment issues. The polling thread's unified capture of callback exceptions also helps prevent single business processing exceptions from causing cascading effects on other topic data processing, thereby improving project maintainability.

[0078] Example 3: Extended Implementation of Adding a New Business Theme

[0079] like Figure 2 As shown in this embodiment, the extension process of this application when adding a new service topic is illustrated. Assuming a new "camera status" telemetry topic is added to an existing system, the extension process may include the following steps.

[0080] Step 1: Define a new Topic. Define the data structure corresponding to the "Camera Status" business in the data model file, and ensure that it conforms to the system's preset serialization specifications.

[0081] Step 2: Add configuration. Add a "Camera Status" topic path constant to the configuration file or module, ensuring that the topic path conforms to the unified naming convention: / {SystemID} / {ServiceType} / {APID} / {InterfaceType} / {TopicFunction}. For example, a unique topic path can be generated based on the system instance identifier, service type, application identifier, interface type, and topic function name to ensure consistency and manageability of topic naming when deploying multiple instances.

[0082] Step 3: Implement the callback function. Write the business processing function corresponding to the "Camera Status" topic in the business logic module. This callback function strictly adheres to the preset function signature and internally contains only calls to the core business library and recording operations to the log storage module.

[0083] Step four, register the callback. In the main system initialization process, the subscription registration interface of the transmission service module is called to register and bind the "Camera Status" topic path, corresponding data type, the data reader bound to this topic, and the aforementioned business processing function. After system startup, the data polling thread can automatically traverse to the data reader bound to the "Camera Status" topic, read data samples, and call the registered business processing function.

[0084] Step 5: System Automatic Processing. After completing the above steps, the polling logic within the transmission service module, the implementation of the log storage module, and the log display logic of the monitoring module do not need to be changed. New business topics can be incorporated into the existing architecture's automatic processing flow. The entire process requires no modification to the code of the transmission service module, message storage module, or monitoring module, achieving plug-and-play functionality for business functions.

[0085] Step six, complete the extension. The system can receive, process, record, and display the newly added "camera status" telemetry data without requiring structural modifications to the existing communication polling framework.

[0086] When adding new business themes, development focuses on data structure definition, configuration supplementation, business processing function writing, and registration and binding, resulting in a relatively clear extension path. Since the data reception and traversal mechanism, exception handling mechanism, log retrieval mechanism, and monitoring display mechanism are already provided by the existing system, there is usually no need to rebuild common infrastructure capabilities when adding new businesses. This approach helps reduce modification points and lowers the probability of regression issues introduced by modifying transmission threads or monitoring logic. Simultaneously, business developers primarily work on the data model and business interfaces, avoiding the need to repeatedly handle the underlying DDS entity organization and thread scheduling logic with each extension, thus contributing to improved extension efficiency and system consistency.

[0087] Example 4: Core Business Encapsulation Implementation Method

[0088] In this embodiment, the core business encapsulation module is used to encapsulate the underlying algorithm library. This underlying algorithm library can be a planning library, a control algorithm library, a state estimation library, or other dynamically linked libraries related to specific business operations. During the system startup phase, it reads the library path parameters from the configuration module, loads the underlying algorithm library using dynamic linking technology, and parses out the preset business processing interfaces, result acquisition interfaces, and state query interfaces.

[0089] If the dynamic library loads successfully, the core business encapsulation module sets its internal availability flag to available and allows business logic modules to initiate calls through the encapsulated interface. If the dynamic library fails to load, for example, due to missing library files, version mismatch, or symbol resolution failure, the core business encapsulation module sets the availability flag to unavailable and records the error reason through the log storage module. Subsequently, when business processing functions execute, they can first query the status of the core business encapsulation module. For business processes that depend on this dynamic library, a degradation strategy can be implemented, such as only logging data without executing the core algorithm call, or recording the status information "Current core business library unavailable" in the log.

[0090] Considering that the data polling thread of the transmission service module and the timed publishing thread of the business logic module may concurrently call the same core business library, this embodiment sets a mutex lock in the core business encapsulation module. The mutex lock is acquired before each call to the underlying algorithm interface and released after the call is completed to prevent multiple threads from simultaneously accessing underlying non-thread-safe resources, which could lead to state corruption, memory access conflicts, or result overwriting issues.

[0091] By encapsulating the underlying algorithm capabilities within independent modules, different algorithm libraries can be exposed to a unified interface, freeing business processing functions from concern themselves with the specific loading methods and thread protection mechanisms of the underlying libraries. Through the introduction of dynamic loading and state exposure mechanisms, the system can maintain the operation of peripheral modules even when the core algorithm library malfunctions, and its availability can be observed through a monitoring module, facilitating problem localization. Mutex locks protect concurrent calls, reducing the probability of exceptions caused by resource contention under multi-threaded conditions, making it suitable for real-time control systems that need to simultaneously receive external data and periodically report calculation results.

[0092] Example 5: Log Storage and Monitoring Implementation Method

[0093] This embodiment illustrates the cooperation between the log storage module and the monitoring module. The log storage module adopts a two-layer storage structure. The first layer is a memory circular queue used to store log records within a recent period to support high-frequency writing and fast reading. The second layer is a disk file used to persistently store historical logs for easy fault tracing and operational auditing. Each log record may include fields such as log identifier, timestamp, topic path, log level, processing result summary, and exception description.

[0094] When a business processing function is triggered, a business processing log can be written to the log storage module; when the polling thread catches a callback exception, an error log can be written; when the core business encapsulation module fails to load or fails to call, the relevant status can also be recorded in the log module. The monitoring module requests new logs through a log retrieval interface based on an identifier increment. Specifically, the monitoring module maintains a recently read log identifier, sends this identifier to the log storage module with each request, and the log storage module returns the set of logs added after the identifier, thus achieving incremental retrieval with low overhead.

[0095] In addition to reading logs, the monitoring module can also read status information from the transmission service module and the core business encapsulation module, such as DDS initialization status, polling thread running status, receive count, send count, core business library availability status, and system runtime, and display this information on the monitoring interface. The monitoring interface can be a web page or other front-end formats with status display capabilities.

[0096] A memory-based circular queue improves throughput in scenarios with high-frequency log writes, while disk persistence meets historical traceability requirements. Combining the two helps achieve a balance between real-time performance and traceability. An incremental fetch mechanism eliminates the need for the monitoring module to retrieve all logs each time, thus reducing monitoring communication overhead. Since anomalies in the transport service layer, business processing, and core business databases can all be uniformly aggregated into the log storage module, maintenance personnel can obtain key system operational information through a single monitoring entry point, thereby improving problem localization efficiency and operational convenience.

[0097] In summary, this application achieves a clear separation between the business logic and the transport layer by constructing a layered structure comprising a configuration module, a transmission service module, a business logic module, a core business encapsulation module, and log storage and monitoring modules. Through a subscription registry, a unified registration interface, and a data polling thread, it forms an extension mechanism suitable for adding new business topics. Furthermore, through core business encapsulation, exception handling, concurrency protection, and incremental log monitoring, it improves the system's scalability, maintainability, testing convenience, and operational stability. This application can be applied not only to satellite ground control systems but also to UAV ground station systems, industrial robot control systems, autonomous driving data distribution systems, and edge computing node control systems.

[0098] This application can be applied not only to satellite ground telemetry and control systems, but also to UAV ground station systems, industrial robot control systems, autonomous driving data distribution systems, and edge computing node control systems, and supports cross-platform deployment, data interoperability between heterogeneous systems, and edge-cloud collaborative control.

[0099] The contents not described in detail in this specification are common knowledge to those skilled in the art.

[0100] This application has been described in conjunction with preferred embodiments, but it is not limited to the embodiments described above. All equivalent substitutions, improvements, or modifications made within the spirit and principles of this application should be included within the scope of protection of this application.

[0101] According to one aspect of this application, an electronic device is provided, comprising: one or more processors, one or more memories, and one or more computer programs; wherein the processor is connected to the memory, and the one or more computer programs are stored in the memory, and when the electronic device is running, the processor executes the one or more computer programs stored in the memory to cause the electronic device to perform a real-time embedded control method as described in any of the above technical solutions.

[0102] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0103] The memory can be an internal storage unit of the terminal device, such as a hard drive or RAM. Alternatively, it can be an external storage device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units. The memory is used to store the computer program and other programs and data required by the terminal device. It can also be used to temporarily store data that has been output or will be output.

[0104] According to one aspect of this application, a computer-readable storage medium is provided for storing computer instructions, which, when executed by a processor, implement a real-time embedded control method as described in any of the above technical solutions.

[0105] For example, computer-readable storage media can be read-only memory (ROM), random access memory (RAM), read-only optical disc (CD-ROM), magnetic tape, floppy disk, and optical data storage devices, etc. They can be implemented using program code executable by a computing device, thus allowing them to be stored in a storage device for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, this application is not limited to any particular hardware and software combination.

[0106] This application provides a distributed real-time embedded control system based on service-transmission decoupling, which has the following advantages:

[0107] Ultimate scalability (plug and play): Adding a new business topic (or any data interaction type) requires only four steps: "define model → add configuration → write callback → register". This reduces the workload of expansion by approximately 70%, and requires no modification to any existing code, eliminating regression risk. This effect is unattainable by existing "configuration-driven" solutions—existing solutions typically require modifications to protocol parsing logic or business processing code when adding new business topics.

[0108] High cohesion and low coupling: Clear responsibilities for each layer—the transport layer only handles sending and receiving and callback distribution, the business layer only focuses on data processing and algorithm invocation, and the storage and monitoring layers evolve independently. Transport layer developers do not need to understand business algorithms, and business developers do not need to worry about DDS configuration. This degree of separation far exceeds that of existing systems.

[0109] Improved system robustness: Exceptions in callback functions are caught and logged by the transport layer, preventing the entire polling thread from crashing and ensuring the continued operation of other system functions. The system can still provide monitoring and logging services even when dynamic loading of the business library fails.

[0110] Improve testing efficiency: Easily simulate the transport layer, inject arbitrary test data into business callbacks, and achieve pure unit testing of business logic without relying on a real DDS network environment. Simultaneously, transport layer behavior can be tested by simulating business library return values.

[0111] Enhanced thread safety: Mutex locks are used to protect dynamic library calls, resolving the data contention issue in a multi-threaded environment.

[0112] Cross-platform and cross-middleware friendly: Since the business layer is completely unaware of the DDS API, when replacing it with other message middleware, only the transport service layer interface needs to be reimplemented, and the business code is modified without any changes, thus realizing the pluggability of the transport middleware.

[0113] The above description is merely one embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A distributed real-time embedded control system based on service-transmission decoupling, characterized in that, include: The configuration module is used to store system operating parameters, which include at least the system identifier, topic path, middleware domain identifier, core business library path, and log capacity. The transmission service module manages the lifecycle of the data distribution middleware and provides subscription registration, publication registration, and data sending and receiving services. The business logic module is used to register the business processing functions corresponding to each business theme to the transmission service module, and call the transmission service module to publish business data; The core business encapsulation module is used to encapsulate the core business library and provide business processing interfaces to the outside world; The log storage module is used to record business processing logs and exception logs; The transmission service module includes a subscription registry and an independently running data polling thread; The subscription registry is used to store the mapping relationship between topic paths, data readers corresponding to topic paths, and business processing functions. The data polling thread is used to traverse the registered data readers at fixed intervals, call the data acquisition interface of the data reader to obtain data samples, and find and execute the corresponding business processing function according to the subscription registry. The business processing function is used to receive the data sample and only performs the following operations: calling the business processing interface provided by the core business encapsulation module and calling the log storage module to record logs; When a new business topic is added, the data structure definition, topic configuration, business processing function writing, and registration binding of the new business topic only need to be completed in the business logic module, without modifying the internal processing logic of the transmission service module.

2. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The transmission service module also includes a registry publishing platform and a unified registration interface. The publishing registry is used to maintain the mapping between topic paths and data writers. The unified registration interface includes at least a subscription registration interface and a publish registration interface. The subscription registration interface is used to associate and register topic paths, data types, data readers, and business processing functions, while the publication registration interface is used to associate and register topic paths, data types, and data writers.

3. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The data polling thread catches exceptions when executing the business processing function and writes the exception information to the log storage module to prevent the data polling thread from exiting due to the failure of a single business processing function.

4. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The business logic module also includes an independent scheduled task thread, which calls the core business encapsulation module to obtain business results according to a preset period, and publishes the business results through the unified publishing interface provided by the transmission service module.

5. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The configuration module is used to generate or store the paths of each topic according to a unified naming convention, which is as follows: / {SystemID} / {ServiceType} / {APID} / {InterfaceType} / {TopicFunction}; Both the transmission service module and the business logic module operate based on the parameters provided by the configuration module to achieve configuration-driven system behavior.

6. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The core business encapsulation module is used to load the core business library via dynamic linking. When the core business library fails to load, the core business encapsulation module sets its own state to unavailable and records an error log, while the transmission service module, business logic module and log storage module continue to run. The core business encapsulation module also provides a status query interface to expose the current availability status.

7. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The core business encapsulation module is equipped with a mutex lock to protect the concurrent calls to the core business library initiated by multiple threads, so as to ensure thread safety when data receiving and processing and timed task processing are executed concurrently.

8. The distributed real-time embedded control system based on service-transmission decoupling according to claim 1, characterized in that, The log storage module adopts a two-layer storage structure that combines a memory circular queue and disk files; The log storage module also provides a log retrieval interface based on identifier increment, which allows the monitoring module to poll for newly added logs and display them in real time.

9. A service extension method for a distributed real-time embedded control system based on service-transmission decoupling as described in any one of claims 1 to 8, characterized in that, Includes the following steps: Step S1: Define the data structure corresponding to the newly added business topic to meet the system's preset data serialization requirements; Step S2: Add the topic path corresponding to the newly added business topic in the configuration module; Step S3: Write a business processing function corresponding to the newly added business topic in the business logic module. The business processing function only executes the business processing interface provided by the core business encapsulation module and the log storage module to record logs. Step S4: During system initialization, the newly added business topic, the corresponding data reader, and the business processing function are bound and registered through the subscription registration interface of the transmission service module. After completing steps S1 to S4, the data polling thread of the transmission service module automatically receives the data of the newly added business topic and calls the corresponding business processing function without modifying the code of the transmission service module, log storage module and monitoring module.

10. The business expansion method according to claim 9, characterized in that, The distributed real-time embedded control system is applied to spacecraft ground telemetry and control systems, UAV ground station systems, industrial robot control systems, autonomous driving data distribution systems, or edge computing node control systems, and supports cross-platform deployment and adaptation and replacement between different message middleware.

Images