Application software architecture for encapsulating task management and synchronization mechanism of operating system

Abstract

The invention discloses an application software architecture for encapsulating a task management and synchronization mechanism of an operating system, and belongs to the technical field of industrial real-time control. According to the architecture, an operating system task management and synchronization mechanism is modularly packaged into three types of objects: an employee type for packaging specific business execution logic; the pipeline class is used for packaging inter-task communication and synchronization functions; and the behavior class is used for packaging an operating system task entity and is responsible for scheduling employee objects contained in the behavior class to be executed orderly. The three types of objects are created, assembled and started through a factory mode according to configuration information to form a complete real-time task system. According to the method, through object-oriented packaging and configuration assembly, the problems of tight task coupling and difficult code maintenance in traditional process-oriented programming are solved, loose coupling and high cohesion among task modules are realized, the configurability, maintainability and expandability of industrial real-time software are remarkably improved, and the method is suitable for various real-time operating system environments.

Description

Technical Field

[0001] This invention belongs to the field of industrial real-time control technology, specifically relating to an application software architecture that encapsulates operating system task management and synchronization mechanisms. Background Technology

[0002] Industrial real-time control and communication systems, such as motion control, data acquisition, and process monitoring, typically run on hard real-time operating systems (RTOS), such as VxWorks, FreeRTOS, and μC / OS. These systems have strict requirements on task execution timing, response latency, and determinism. Traditional development models primarily employ procedural C programming, where developers directly call native APIs provided by the operating system (such as task creation, semaphores, and message queues) to build applications. Specifically, this involves directly writing or calling a series of function calls within the task entry function, and hard-coding communication and synchronization logic (such as waiting for semaphores and read / write queues) within these function flows.

[0003] However, this traditional approach has significant drawbacks: First, the business logic, task management, and communication mechanisms are highly coupled, resulting in a chaotic "pasty" code structure. Any change to a function can trigger a chain reaction of modifications, leading to high development and maintenance costs. Second, because communication and synchronization logic are scattered and fixed within various functionalities, it is difficult to optimize the overall performance and dynamically adjust the scheduling. Furthermore, this tightly coupled architecture results in extremely poor code reusability, making it impossible to quickly adapt to changing requirements or be ported to different hardware platforms. While some modular or framework-based attempts have been made, they typically fail to thoroughly decouple the operating system's task entities, communication primitives, and business logic using object-oriented principles, nor do they provide a configurable, unified assembly mechanism. Consequently, when dealing with complex real-time task flows, they still cannot balance flexibility, maintainability, and real-time performance.

[0004] Therefore, there is an urgent need in this field for an innovative software architecture that can achieve a clear separation of task management, communication synchronization and business logic while maintaining hard real-time performance, and can flexibly assemble the system through configuration, thereby fundamentally improving the development efficiency, maintainability and scalability of industrial real-time software. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides an application software architecture that encapsulates the task management and synchronization mechanisms of an operating system. By applying the object-oriented principles of large-scale application software, the tasks and their communication synchronization functions provided by the operating system are encapsulated into C++ classes. This allows tasks and their communication synchronization functions to be managed modularly as C++ objects. This approach completely decouples the tight coupling defects of hard-coded business processing function positions and orders in procedural programming, and achieves loose coupling between modules through configuration.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] An application software architecture that encapsulates the task management and synchronization mechanisms of an operating system includes:

[0008] The Employee class module encapsulates the application's business execution logic, including calling input pipe members and output pipe receive and send functions, and implementing the doWork virtual function for executing business logic;

[0009] The behavior module is used to encapsulate operating system tasks, including at least one employee class module instance as its member, and is responsible for calling the doWork virtual function of its employee class module instances in the order of assembly within the task context.

[0010] The pipeline module is used to encapsulate inter-task communication and synchronization mechanisms. It provides an Emit interface for sending messages or synchronization signals and a Retrieve interface for receiving messages or obtaining synchronization signals.

[0011] The factory module is used to create instances of employee, pipeline, and behavior modules based on configuration information, connect the modules through pipeline module instances, and finally start the operating system task encapsulated in the behavior module.

[0012] Furthermore, the employee class module also includes an init virtual function for object initialization.

[0013] Furthermore, the pipe module is divided into blocking pipes and non-blocking pipes based on whether they are blocked.

[0014] Furthermore, the blocking pipe includes a message queue pipe, which is used to buffer multiple data packets and block the receive operation when the queue is empty.

[0015] Furthermore, the non-blocking pipe includes a transparent copy pipe for caching the latest single data packet without blocking the receive operation.

[0016] Furthermore, in the doWork virtual function of the employee class module, input data is obtained through the Retrieve interface of the input pipe member, and output data is sent through the Emit interface of the output pipe member.

[0017] Furthermore, the system also includes a configuration table module, which provides the configuration information required for the factory module to create and configure various module instances.

[0018] Furthermore, when at least one employee class module instance is included in the same behavior class module instance, it is executed sequentially by the behavior class module instance.

[0019] Furthermore, the factory module creates corresponding employee class module, pipeline class module, and behavior class module instances based on the type identifier.

[0020] Furthermore, the communication and synchronization mechanism types encapsulated by the pipeline module include at least one of message queues, binary semaphores, counting semaphores, or non-blocking communication methods.

[0021] The beneficial effects of this invention are as follows:

[0022] Clear architecture and high decoupling: The underlying tasks, communication, and business functions of the operating system are encapsulated into behavior classes, pipe classes, and employee classes, respectively, achieving a complete separation between the task scheduling mechanism, communication synchronization logic, and specific business execution. Each module of the system has clearly defined responsibilities and interfaces, fundamentally changing the traditional "spaghetti" code structure of procedural programming and significantly reducing the coupling between modules.

[0023] Flexible configuration and easy maintenance: By using the factory pattern and external configuration tables to drive the creation and assembly of objects, the construction, modification, and expansion of task flows can be completed without delving into the code; only configuration adjustments are needed. This greatly improves the system's flexibility in responding to changing requirements, simplifies maintenance and upgrade processes, and significantly shortens the development cycle.

[0024] Controllable real-time performance and high resource efficiency: The pipe class encapsulates various communication synchronization mechanisms, including blocking and non-blocking, allowing precise control of task scheduling and data flow according to real-time requirements. While ensuring the determinism of hard real-time tasks, the system can intelligently schedule non-real-time tasks, optimizing the utilization of resources such as CPU.

[0025] Enhanced code reuse and platform adaptability: Standardized class interface design enables high reusability of modules such as employees and pipelines across different projects. This architecture is isolated from specific operating system APIs, allowing for easy porting to various RTOS platforms such as VxWorks and FreeRTOS through an adaptation layer, thus increasing the value and applicability of software assets. Attached Figure Description

[0026] Figure 1 A schematic diagram illustrating the requirements for an industrial computing control example;

[0027] Figure 2 This is a schematic diagram illustrating how the present invention is applied to implement the requirements of an example. Detailed Implementation

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0029] This invention applies C++ object-oriented principles, encapsulating operating system task functionality into behavior classes, task communication and synchronization into pipe classes, and application business execution functions into employee classes. These classes are created using a factory pattern, producing and assembling class members at the top level solely through type and configuration. Finally, the real-time operating system task encapsulated in the behavior classes is launched to run the entire real-time use case. The specific solution is as follows:

[0030] 1. Business Logic Encapsulation Unit – Employee Class: The Employee class is the basic execution unit for application business functions. Each Employee class object includes:

[0031] Input / output pipe member variables: used to connect upstream and downstream business modules to achieve the transmission of data and synchronization signals.

[0032] The virtual initialization function (init) is called when an object is created and is used to configure specific parameters and states of an employee.

[0033] The virtual function `doWork` serves as the entry point for business logic execution. Within this function, the employee retrieves input data or synchronization signals (blocking or non-blocking) by calling the `Retrieve` method of its input pipe object. After performing business calculations or processing, it sends out results or trigger signals through the `Emit` method of its output pipe object. Specifically, when the input pipe is empty and in blocking mode, the `doWork` function can be suspended, thereby proactively releasing CPU resources.

[0034] 2. Task Execution Management Unit – Action Class: The action class is an object-oriented encapsulation of operating system tasks (Task / Thread), serving as an execution container and scheduler for employee objects. It includes:

[0035] Employee class member variable collection: used to hold one or more employee objects that need to be executed sequentially for this task.

[0036] Task initialization function: Creates and initializes the corresponding operating system task, but does not run the task immediately.

[0037] Task execution logic: Within the encapsulated operating system task context, the `doWork` method of all its owned employee objects is called in a loop or in a preset order to achieve task-level scheduling. Different behavior classes can correspond to real-time tasks with different priorities and different periods.

[0038] 3. Communication and Synchronization Mechanism Encapsulation Unit – Pipe Class: The pipe class encapsulates various inter-task communication and synchronization primitives provided by the operating system, serving as a standardized interface for interaction between employees. It includes:

[0039] Typed encapsulation: Different specific pipe classes are derived based on the underlying mechanism (such as message queues, binary semaphores, counting semaphores, event flag groups, etc.) and blocking characteristics.

[0040] Emit Interface: Available for use by source employees to send data messages or release synchronization signals into the pipeline.

[0041] The Retrieve interface is used by end-users to retrieve data messages or request synchronization signals from the pipeline. This interface can either block and wait or return immediately, depending on the pipeline type.

[0042] 4. System Construction and Operation Control Unit – Implementation using the Factory Pattern; The factory pattern is used to uniformly manage the lifecycle and assembly relationships of all class objects within the system.

[0043] Object creation factory: Dynamically creates corresponding employee, pipeline, and behavior object instances based on configuration information (such as type enumerations or macro definitions).

[0044] Dependency Injection and Configuration: The factory is responsible for injecting the necessary pipeline dependencies into each object instance, passing initialization parameters, and completing the logical connections between objects.

[0045] System Initiator: After the factory completes the creation and assembly of all objects, it uniformly starts the underlying operating system tasks encapsulated in each behavioral object, thereby starting the entire real-time application use case.

[0046] 5. Configuration-driven system assembly; This involves describing the required employee types, pipeline types, behavioral structures, and their connections within the entire system using externally configurable data structures (such as configuration tables or XML files). This configuration information serves as input to the factory, driving system generation and achieving a flexible "configuration as assembly" architecture. Configuration tables are used as input to the factory to configure the creation and configuration information for the entire use case.

[0047] Example

[0048] like Figure 1 The diagram illustrates an example of industrial computational control: its inputs are a 4kHz motion physical quantity A plus a 1Hz temperature acquisition B, a 400Hz core calculation C, a 200Hz result output D, and a 200Hz result storage E. A, C, and D have real-time requirements, while B and E do not.

[0049] like Figure 2 The diagram shown is a schematic of how the present invention is applied to implement the requirements of an example. Specifically, five employees, A, B, C, D, and E, are designed.

[0050] The behavioral members are designed as follows: real-time data collection behavior α, which includes employee A; non-real-time data collection behavior β, which includes employee B; calculation behavior γ, which includes employees C and D; and storage behavior δ, which includes employee E.

[0051] The doWork function of employee A collects motion physical quantities from the driver layer. After collecting a complete packet, it sends it to C through the Emit function of its output pipe No. 0. The output pipe No. 0 of employee A is a blocking message queue with a global number of a. It can buffer several packets of motion physical quantity messages. When the queue is empty, it blocks the Retrieve function called by the subsequent employee.

[0052] The doWork function of employee B collects temperature physical quantities from the driver layer. After collecting a complete packet, it sends it to C through the Emit function of its output pipe number 0. The output pipe number 0 of employee B is a non-blocking transparent copy with a global number of b. It can only buffer the latest message packet and does not block the Retrieve function called by subsequent employees.

[0053] The doWork function of employee C first receives the motion physical quantity sent by employee A in blocking mode through the Retrieve function of its input pipe 0 (a). After collecting the data 10 times, it receives the latest temperature physical quantity sent by employee B in non-blocking mode through the Retrieve function of its input pipe 1 (b). Then, it performs business calculations, and sends the calculation results to employees D and E respectively through the Emit functions of its output pipe 0 (c) and its output pipe 1 (d).

[0054] Employee D's doWork retrieves the computation results sent by Employee C through the Retrieve function of its input pipe (c) number 0. Since Employees C and D work sequentially within the same action member, D's doWork will always be executed after C's doWork is completed. Therefore, using a non-blocking transparent pipe can ensure data synchronization between the two employees. D's doWork outputs a packet of data results to the underlying driver every two executions.

[0055] Employee E's doWork uses the Retrieve function of its input pipe 0 (d) to obtain the calculation results sent by Employee C in a blocking manner and perform non-real-time data storage. E's doWork calls the file system driver to write data records. Due to the non-real-time nature of the file system driver, E's input pipe (d) is a large-capacity message queue to meet the requirement of storing data without loss.

[0056] In summary, this invention provides an innovative real-time task management and synchronization architecture. Through object-oriented encapsulation, modular design, and configurable assembly, it effectively solves the core problems that have long existed in the field of industrial control, such as task coupling, difficult code maintenance, and insufficient system flexibility. This architecture clearly separates the underlying operating system mechanism from the upper-layer application logic, which not only ensures the performance determinism of the hard real-time system but also greatly improves the software's reusability, configurability, and scalability.

[0057] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An application software architecture encapsulating operating system task management and synchronization mechanisms, characterized by, The system comprises: an employee class module for encapsulating application business execution logic, including calling input pipe member and output pipe receiving and sending functions, and implementing a doWork virtual function for executing business logic; a behavior class module for encapsulating an operating system task, including at least one employee class module instance as a member, and being responsible for calling the doWork virtual function of the employee class module instance contained therein in the task context according to the assembly order; a pipe class module for encapsulating inter-task communication and synchronization mechanisms, providing an Emit interface for sending messages or synchronization signals, and providing a Retrieve interface for receiving messages or obtaining synchronization signals; a factory module for creating instances of the employee class module, the pipe class module, and the behavior class module according to configuration information, connecting the modules through the pipe class module instances, and finally starting the operating system task encapsulated in the behavior class module.

2. The application software architecture encapsulating the operating system task management and synchronization mechanism according to claim 1, wherein, The employee class module further comprises an init virtual function for object initialization.

3. The application software architecture encapsulating the operating system task management and synchronization mechanism according to claim 1, wherein, The pipe class module is divided into a blocking pipe and a non-blocking pipe according to whether it blocks.

4. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 3, wherein, The blocking pipe comprises a message queue pipe for buffering multiple data packets and blocking the receiving operation when the queue is empty.

5. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 3, wherein, The non-blocking pipe comprises a transparent copy pipe for buffering the latest single data packet and not blocking the receiving operation.

6. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 1, wherein, In the doWork virtual function of the employee class module, input data is obtained through the Retrieve interface of the input pipe member, and output data is sent through the Emit interface of the output pipe member.

7. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 1, wherein, The system further comprises a configuration table module for providing configuration information required by the factory module to create and configure instances of various modules.

8. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 1, wherein, When the at least one employee class module instance is contained in the same behavior class module instance, the behavior class module instance sequentially schedules and executes the employee class module instance.

9. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 1, wherein, The factory module creates corresponding instances of the employee class module, the pipe class module, and the behavior class module according to type identifiers.

10. The application software architecture encapsulating the operating system task management and synchronization mechanism of claim 1, wherein, The communication and synchronization mechanisms encapsulated by the pipe class module include at least one of a message queue, a binary semaphore, a counting semaphore, or a non-blocking communication mode.

Images