Aerospace servo system software framework control method with high reliability

Abstract

This invention discloses a highly reliable control method for aerospace servo system software framework, comprising the following steps: S1: establishing monitoring modules corresponding to each function of the aerospace servo system software framework; S2: a fault judgment module performs fault judgment on the status of the monitoring modules; S3: a fault handling module performs reset recovery, hot switching, fault-tolerant operation, and shutdown on the monitoring modules based on the fault judgment results. This invention not only achieves precise fault location and isolation, directly addressing the root cause and avoiding a crude, one-size-fits-all approach, but also improves the system's reconfigurability and recovery efficiency. Because the fault is precisely located in a specific software function module, the recovery strategy can be extremely refined and rapid, greatly shortening the fault recovery time and improving system availability and mission success rate.

Description

Technical Field

[0001] This invention relates to the field of servo system control, and more particularly to a software framework control method for aerospace servo systems with high reliability. Background Technology

[0002] Servo software frameworks are the core of industrial automation, and their reliability directly determines the safety of the system. Aerospace servo systems are the core actuators of aircraft flight control systems. Essentially, they are high-precision, high-reliability position or force servo control systems. They receive command signals from the flight control computer, amplify and convert power through servo drivers and servo motors (such as permanent magnet synchronous motors), and drive loads such as control surfaces, nozzles, and valves via mechanical transmission devices. Simultaneously, they utilize sensors (such as resolvers) to provide real-time feedback on physical quantities such as position and velocity, forming a closed-loop control system to precisely manipulate the aircraft's attitude, trajectory, and various mission payloads. In the aerospace field, a single failure of a servo system can lead to enormous financial losses. Therefore, software framework design must prioritize fault prevention, rapid diagnosis, and fault-tolerant operation, building a reliable system through framework isolation.

[0003] The reliability issues of traditional servo software frameworks are essentially centered on functionality—that is, how the system perfectly executes preset tasks when everything is normal—rather than on fault prevention, which involves preventing failures before they occur, isolating them during failures, and rapidly self-healing after failures to maintain maximum system availability. The main problems are as follows: In existing technologies, fault detection and prevention often start from the system perspective. When the core control algorithm encounters an error (such as division by zero, data overflow, or entering an abnormal state), the entire control loop collapses because there is no built-in, readily available backup algorithm. The most direct recovery method is to restart the entire software, and even the entire hardware device. However, during the restart, service is interrupted, meaning the servo system is completely out of control, which is fatal for high-precision, high-real-time applications (such as industrial robots and aerospace). Furthermore, it equates the failure of one algorithm module with the failure of the entire system, a crude and one-size-fits-all approach. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a highly reliable aerospace servo system software framework control method.

[0005] The objective of this invention is achieved through the following technical solution:

[0006] A first aspect of the present invention provides a highly reliable aerospace servo system software framework control method, comprising the following steps:

[0007] S1: Establish the monitoring modules corresponding to each function of the aerospace servo system software framework;

[0008] S2: The fault judgment module performs fault judgment on the status of the module to be monitored;

[0009] S3: Based on the fault judgment result, the fault handling module performs reset recovery, hot switching, fault-tolerant operation and shutdown on the monitored module.

[0010] Further, in step S1, the modules to be monitored corresponding to each function of the aerospace servo system software framework include:

[0011] The servo system is divided into a driver layer, a functional layer, and an application layer. The modules to be monitored include the driver module of the driver layer, the functional module of the functional layer, and the application module of the application layer.

[0012] The driver module in the driver layer connects the hardware with the functional layer and the application layer, isolates hardware differences, and provides standardized interfaces. The functional modules in the functional layer are the smallest modules that implement various functions of the servo system. If there is an actual physical device, they are divided according to the independent physical device, and the driver module in the driver layer is called according to the actual needs. If there is no actual physical device, they are divided according to the independent functions. The application modules in the application layer are divided according to the user requirements, and the functional modules in the functional layer are called according to the actual needs.

[0013] Furthermore, in step S1, the monitoring modules corresponding to each function of the aerospace servo system software framework also include:

[0014] Add separate data pools for the driver layer, the functional layer, and the application layer. The functional layer uses pointers to access data in the driver layer data pool, and the application layer uses pointers to access data in the functional layer data pool.

[0015] Furthermore, the driver layer is divided into independent driver layer modules according to the peripherals, and its operation depends on the main control chip;

[0016] The driver layer selects the corresponding driver layer module according to the functional layer requirements; and implements module encapsulation based on the standard library or HAL library provided by the chip manufacturer; the module encapsulation includes: establishing data structures and establishing functional interfaces.

[0017] Furthermore, for the functional layer, the functional layer module encapsulation implementation is as follows: establish a data structure, and if the driver layer is needed, a pointer is required to retrieve data from the driver layer data pool; establish a functional interface.

[0018] Furthermore, for the application layer, the application layer is used to connect various functional layer modules to form the functions required by the system. The application layer modules select the corresponding functional modules according to the actual application requirements and use pointers to retrieve data from the functional module's data pool.

[0019] Furthermore, the method also includes an initialization step located between step S1 and step S2:

[0020] S1': After power-on, the application layer configures all parameters of the data pool using default data or data read from other storage modules. It initializes the corresponding modules, including the application layer, functional layer, and driver layer, based on the parameters in the data pool. Then, it enters a while loop, which includes modules such as the communication processing module, the fault judgment module in step S2, and the fault handling module in step S3.

[0021] Further, in step S2, the fault judgment module performs fault judgment on the status of the module to be monitored, including:

[0022] Fault detection is divided into module-level fault detection and system-level fault detection. Module-level fault detection is integrated into the driver modules of each driver layer and the functional modules of each functional layer. The basis for module-level fault detection depends only on the internal data of the corresponding module, and the detection result only needs to output whether the corresponding module is faulty. System-level fault detection is integrated into the application layer. The application layer collects data from the functional modules of the functional layer and uses multi-source information analysis to locate the faulty module.

[0023] Further, in step S3, the fault handling module performs reset recovery, hot switching, fault-tolerant operation, and shutdown on the monitored module based on the fault judgment result, including:

[0024] The fault handling module takes targeted fault handling measures based on the fault detection and location results; wherein, the fault handling measures include:

[0025] Module reset is performed on the driver modules of the driver layer and the functional modules of the functional layer that have actual physical devices and can be reset. When a corresponding module fails, a hardware reset is performed on the corresponding module.

[0026] Module hot switching is used for functional modules at the functional layer that do not have actual physical devices, as well as application modules at the application layer. When a corresponding module fails, the importance level of the corresponding module is determined. If it is a core critical program including communication processing, motor drive, and control, the backup module is activated. The backup module has the same function as the original module.

[0027] "Operation with fault tolerance" refers to the operation of driver modules in the driver layer, functional modules in the functional layer, and application modules in the application layer. If the corresponding module fails, the core functions of the system are not affected, and the system continues to operate with fault tolerance.

[0028] Shutdown, for driver modules in the driver layer, functional modules in the functional layer, and application modules in the application layer, occurs when other modules are unable to support the system to meet the minimum core functions after a failure. In this case, shutdown causes the servo system to stop operating or switch to redundancy.

[0029] The beneficial effects of this invention are:

[0030] In an exemplary embodiment of the present invention, not only is accurate fault location and isolation achieved, directly addressing the root cause of the function and avoiding a crude, one-size-fits-all approach, but the system's reconfigurability and recovery efficiency are also improved. Since the fault is accurately located in a specific software functional module, the recovery strategy can become extremely refined and rapid, greatly shortening the fault recovery time and improving the system's availability and task success rate. Attached Figure Description

[0031] Figure 1 This is a flowchart of a highly reliable aerospace servo system software framework control method provided in an exemplary embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram illustrating the relationship between the driver layer, functional layer, application layer, and data pool provided in an exemplary embodiment of the present invention.

[0033] Figure 3 This is a schematic diagram of the initialization steps provided in an exemplary embodiment of the present invention;

[0034] Figure 4 This is a schematic diagram illustrating the steps after initialization is completed in an exemplary embodiment of the present invention. Detailed Implementation

[0035] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0036] See Figure 1 , Figure 1 A flowchart illustrating a highly reliable aerospace servo system software framework control method provided in an exemplary embodiment of the present invention is shown, including the following steps:

[0037] S1: Establish the monitoring modules corresponding to each function of the aerospace servo system software framework;

[0038] S2: The fault judgment module performs fault judgment on the status of the module to be monitored;

[0039] S3: Based on the fault judgment result, the fault handling module performs reset recovery, hot switching, fault-tolerant operation and shutdown on the monitored module.

[0040] Specifically, in this exemplary embodiment, in step S1, the software framework of the aerospace servo system is first deconstructed to identify and establish the correspondence between all key functions and their software modules. Each identified module to be monitored is treated as an independent health management unit, assigned clear inputs, outputs, and internal state variables. This step is the foundation for achieving refined fault management, aiming to provide a comprehensive and thorough monitoring network for subsequent fault diagnosis, ensuring that every functional link of the system is observable. Then, in step S2, the fault judgment module continuously performs fault judgment on all modules to be monitored, and in step S3, the fault handling module executes a preset, differentiated recovery strategy based on the diagnostic results provided by the fault judgment module.

[0041] In summary, this exemplary embodiment has the following advantages:

[0042] (1) Achieving precise fault location and isolation: This exemplary embodiment can penetrate physical devices and systems to reach the root cause of the function; for example, it can locate whether the output of the position loop PID calculation module is saturated, the data of the current sampling and filtering module is abnormal, or the communication protocol parsing module times out. This precise location is the basis for achieving efficient repair and avoids the crude treatment of one-size-fits-all.

[0043] (2) Improve system reconfigurability and recovery efficiency: System / device level monitoring recovery methods are usually very simple: switch the entire hardware channel when the device fails; restart the entire system when the system is abnormal. The whole process is time-consuming, interrupts service, and may mistakenly kill healthy components. The advantages of module monitoring in this exemplary embodiment are: since the fault is accurately located in a certain software function module, the recovery strategy can be extremely refined and fast; and a single algorithm module can be soft reset instead of restarting the entire processor; it can instantly switch to the backup algorithm (software redundancy) of the function module to achieve seamless recovery; it greatly shortens the fault recovery time and improves the system availability and task success rate.

[0044] The following will describe each preferred embodiment in detail:

[0045] More preferably, in an exemplary embodiment, in step S1, the modules to be monitored corresponding to each function of the aerospace servo system software framework are, for example... Figure 2 As shown, it includes:

[0046] The servo system is divided into a driver layer, a functional layer, and an application layer. The modules to be monitored include the driver module of the driver layer, the functional module of the functional layer, and the application module of the application layer.

[0047] The driver module in the driver layer connects the hardware with the functional layer and the application layer, isolates hardware differences, and provides standardized interfaces. The functional modules in the functional layer are the smallest modules that implement various functions of the servo system. If there is an actual physical device, they are divided according to the independent physical device, and the driver module in the driver layer is called according to the actual needs. If there is no actual physical device, they are divided according to the independent functions. The application modules in the application layer are divided according to the user requirements, and the functional modules in the functional layer are called according to the actual needs.

[0048] Specifically, in this exemplary embodiment, the system is divided into modules according to a vertically layered + horizontally modular architecture, namely a driver layer, a functional layer, and an application layer. The driver layer is used to drive the chip's related peripherals; the functional layer is divided according to the independent physical device model if there is an actual physical device, otherwise it is divided according to the independent function; the application layer is based on fulfilling user requirements and calls the application layer functions to implement the servo system functions.

[0049] The driver layer is the intersection of software and hardware. Its core responsibility is to encapsulate hardware differences and provide a unified, standardized software interface for upper layers. The modules to be monitored in the driver layer (i.e., driver modules) correspond one-to-one with specific physical hardware. For example, a resolver decoder driver module interacts directly with an RDC chip or dedicated decoding circuit, converting raw, hardware-dependent electrical signals (such as analog sine / cosine signals or digital pulses) into standardized position / velocity digital quantities that the upper layers can understand. Monitoring these modules is equivalent to monitoring the health of the bridge connecting the software and hardware worlds.

[0050] The functional layer is the implementation carrier of the core control functions of the servo system. The modules to be monitored in the functional layer (i.e., functional modules) are the smallest and most cohesive software units for implementing system functions. Their partitioning principles are closely linked to physical reality: for functions supported by clearly defined physical devices, modules are divided based on independent physical devices, such as the motor drive module for a permanent magnet synchronous motor or the CAN bus communication protocol stack module, which must call the corresponding modules in the drive layer to access the specific hardware; for pure algorithmic functions without independent physical devices, they are divided according to independent, reusable functional units, such as the position loop PID control module, the speed planning curve generation module, or the sensor data fusion module. Monitoring this layer means being able to directly observe the execution status of the system's core control logic.

[0051] The application layer, geared towards the final task, serves as the decision-making and coordination center for system functions. The modules to be monitored in the application layer (i.e., application modules) are divided based on achieving specific, user-oriented tasks. They coordinate and invoke modules from one or more functional layers to complete complex operational sequences. For example, the control surface position servo application module invokes the position loop PID module, torque control module, and CAN communication module. Monitoring this layer allows for the evaluation of the system's overall behavior and performance from a top-level task perspective.

[0052] By adopting a three-layer architecture model consisting of a driver layer, a functional layer, and an application layer, we systematically deconstructed and modeled the software framework of aerospace servo systems, thereby identifying all modules to be monitored. Through this layered and modular modeling approach, we constructed a comprehensive and hierarchical monitoring network covering everything from low-level hardware operations to high-level task execution. This ensures that faults can be located at the most specific software functional unit, enabling accurate diagnosis and intelligent recovery. It also achieves hardware isolation, functional decoupling, and separation of concerns, laying a solid foundation for subsequent precise fault management.

[0053] More preferably, in an exemplary embodiment, in step S1, the modules to be monitored corresponding to each function of the aerospace servo system software framework are, for example... Figure 2 As shown, it also includes:

[0054] Add separate data pools for the driver layer, the functional layer, and the application layer. The functional layer uses pointers to access data in the driver layer data pool, and the application layer uses pointers to access data in the functional layer data pool.

[0055] Specifically, in this exemplary embodiment, based on the driver layer, functional layer, and application layer, a data pool is added to achieve independence between the various modules and avoid mutual interference between them. Specifically:

[0056] (1) Three-layer partitioning design of the data pool: The data pool is divided into three areas, with each layer corresponding to one area. The functional layer can share data with the driver layer and the application layer (i.e., the functional layer modules can read and write the data areas of the driver layer and the application layer). The driver layer and the application layer cannot share data. To solve the problem of high coupling between the functional layer and the driver layer, and between the various modules of the functional layer, the various modules no longer interact directly, but instead interact through a data pool. Information sharing between modules is achieved through pointers. When each function in each layer of the servo framework needs to call or update data, it needs to retrieve data from the data pool. This forces the dependency direction to be singular, that is, the driver layer serves the functional layer, and the functional layer serves the application layer, avoiding complex bidirectional dependencies and circular calls.

[0057] (2) Module decoupling and data uniqueness:

[0058] (2-1) Solving the problem of direct interaction: In some existing technologies, a module in the functional layer (such as the position ring) needs to directly call a module in the driver layer (such as the encoder reader) to obtain data. This tight coupling means that once the interface of the encoder reader module changes, the position ring module must modify its code and retest. In this exemplary embodiment, all modules no longer interact directly. The position ring module only needs to obtain the latest position information from the driver layer data area of ​​the data pool, without needing to know which driver module provided the data. Similarly, the result it calculates is written to the functional layer data area of ​​the data pool for use by other modules (such as the application layer module). This model greatly reduces the coupling between modules.

[0059] (2-2) Ensure the uniqueness of data objects: Each critical data object in the system (such as the actual position of a motor) exists only once in the data pool. All modules that need to read or modify this data point to this unique data entity through pointers. This brings two major benefits: avoiding data inconsistency and eliminating logical errors caused by multiple copies being out of sync; reducing the impact of changes: when the structure or meaning of a data object needs to be modified, its impact is isolated within the data pool and the few modules that directly use it, without affecting all levels of the entire system.

[0060] In summary, this exemplary embodiment addresses the issues of direct calls between modules, high coupling, and chaotic data flow by introducing a global central data pool as the sole hub for information interaction among all modules. Each module focuses solely on implementing its core functions and communicates with the outside world through the data pool interface, making modules more independent and easier to develop, test, and reuse. A module's failure (such as an abnormal crash or data anomaly) can be isolated within the data pool. By monitoring the effectiveness of the data pool, error propagation can be prevented, creating conditions for fault isolation and recovery.

[0061] In a specific exemplary embodiment, each region is divided into different data segments according to the instantiation of the module. For example, the driver layer consists of 2 ADCs, 2 PWMs, and 1 SCI module, while the data pool contains data segments such as ADC1, ADC2, PWM1, PWM2, and SCI. ADC1 and ADC2 are instantiated from the ADC module of the driver layer.

[0062] The following description illustrates exemplary embodiments of the driver layer, functional layer, application layer, steps S2, and S3. Taking a linear brushless DC motor servo system as an example, the servo system needs to receive position control commands from the host computer and control the motor position to run according to the commands. The main control chip receives the converted RS422 command signal through the SCI serial port peripheral, parses the command, and sets the position setpoint of the servo motor; it acquires the servo motor position voltage signal through the on-chip ADC peripheral; finally, it calculates the position deviation and outputs the control command to the motor.

[0063] More preferably, in an exemplary embodiment, the driver layer is divided into independent driver layer modules according to the peripherals, and their operation depends on the main control chip;

[0064] The driver layer selects the corresponding driver layer module according to the functional layer requirements; and implements module encapsulation based on the standard library or HAL library provided by the chip manufacturer; the module encapsulation includes: establishing data structures and establishing functional interfaces.

[0065] Specifically, in this exemplary embodiment, the driver layer is divided into independent modules according to peripherals, and its operation depends on the main control chip. The driver layer selects the corresponding driver module according to the functional layer requirements. Since the peripheral interfaces of different chip manufacturers are different, it is necessary to add encapsulation based on the standard library or HAL library provided by the chip manufacturer. The specific implementation of encapsulation is as follows:

[0066] (1) Establish data structure

[0067] The standard normal form of a data structure is as follows:

[0068] struct xxx_struct

[0069] {

[0070] uint16 ch;

[0071] Parameter 1;

[0072] Parameter 2;

[0073] ...

[0074] }

[0075] xxx represents the peripheral name; ch represents the corresponding peripheral number. For example, if the chip needs to use 4 SCI serial ports, ch 1, 2, 3, and 4 correspond to serial port 1, serial port 2, serial port 3, and serial port 4, respectively. The remaining parameters are set according to the functions of each peripheral. This structure is the same for driver modules of different chips with the same function. Due to differences in chips, some parameters may be useless, but they still need to be retained.

[0076] (2) Establish functional interfaces

[0077] The functional interface is named xxx_yyy(xxx_struct *x, parameter 1, ...); where xxx is the peripheral name and yyy is the interface function. Taking SCI serial port transmission as an example, the API interface can be named SCI_Tx(SCI_struct *x, parameter 1, ...), indicating that the SCI serial port transmission interface needs to use the corresponding SCI object. The remaining parameters are set according to the functions of each peripheral. For driver modules with the same function but different chips, this functional interface is the same, and the related functions are designed according to the requirements of the servo system.

[0078] More preferably, in an exemplary embodiment, for the functional layer, the functional layer module encapsulation implementation is as follows: establishing a data structure, if the driver layer is needed, then a pointer is used to retrieve data from the driver layer data pool; establishing a functional interface.

[0079] Specifically, in this exemplary embodiment, if the functional layer has actual physical devices, it is divided according to independent physical devices; otherwise, it is divided according to independent functions. Functional layer modules can run on all MCU platforms. If hardware is required, it cannot be directly called; the standard interface provided by the driver layer must be used. Taking the control of a linear servo as an example, it consists of a displacement sensor, a brushless DC motor, a Hall sensor, etc. According to traditional methods, all related functions are completed in the motor control module. However, according to the requirements of this project, it is divided into modules for displacement sensors, brushless DC motors, Hall sensors, etc. The functional layer module encapsulation implementation is as follows:

[0080] (1) Establish data structure

[0081] The standard normal form of a data structure is as follows:

[0082] struct ggg_struct

[0083] {

[0084] xxx_struct *x;

[0085] Parameter 1;

[0086] Parameter 2;

[0087] ...

[0088] }

[0089] ggg is the module name; if a driver layer is needed, a *x pointer must be used, otherwise it can be omitted; the remaining parameters are set according to the functions of each peripheral.

[0090] Taking a Hall sensor as an example, its module object can be written as:

[0091] struct HALL_struct()

[0092] {

[0093] GPIO_struct *p_gpio[3];

[0094] Uint8 hall_num; ........

[0095] }

[0096] The above module objects require the use of three GPIO objects from the driver layer, indicating that the level status of the three HALL input ports needs to be read. The hall_num parameter indicates the current position of the motor rotor read by the Hall sensor.

[0097] 2) Establish functional interfaces

[0098] The functional interface is named xxx_yyy(xxx_struct *x, parameter 1, ...); xxx is the name of the functional module; yyy is the function of the interface; the remaining parameters are designed according to the functions of each module.

[0099] Taking the Hall sensor as an example again, the functional interface for reading the Hall sensor is as follows:

[0100] The HALL_Read(HALL_struct *p_hall) function calls the driver layer's GPIO read interface to calculate the position of the Hall sensor and store it in hall_num.

[0101] More preferably, in an exemplary embodiment, the application layer is used to connect various functional layer modules to form the functions required by the system. The application layer module selects the corresponding functional module according to the actual application requirements and uses pointers to retrieve data from the functional module data pool.

[0102] Specifically, in this exemplary embodiment, the application layer is used to connect the various functional layer modules to form the functions required by the system. Since system requirements are complex and varied, the corresponding functional modules are selected based on actual application needs.

[0103] More preferably, in an exemplary embodiment, such as Figure 3 As shown, the method further includes an initialization step located between step S1 and step S2:

[0104] S1': After power-on, the application layer configures all parameters of the data pool using default data or data read from other storage modules. It initializes the corresponding modules, including the application layer, functional layer, and driver layer, based on the parameters in the data pool. Then, it enters a while loop, which includes modules such as the communication processing module, the fault judgment module in step S2, and the fault handling module in step S3.

[0105] Additionally, after the module initialization is complete, such as Figure 4 As shown, the control interrupt will be automatically enabled. The interrupt time and other related parameters of the control interrupt are determined by the relevant parameters in the data pool. After the control interrupt is responded to, the feedback acquisition and processing module collects the system signal. The servo control outputs the control signal according to the feedback signal. The fault detection and processing module determines whether the current system is faulty based on the information fusion between multiple modules. It takes corresponding measures according to the faulty module. Finally, the hardware driver module outputs the control signal to the hardware.

[0106] More preferably, in an exemplary embodiment, in step S2, the fault judgment module performs fault judgment on the state of the module to be monitored, including:

[0107] Fault detection is divided into module-level fault detection and system-level fault detection. Module-level fault detection is integrated into the driver modules of each driver layer and the functional modules of each functional layer. The basis for module-level fault detection depends only on the internal data of the corresponding module, and the detection result only needs to output whether the corresponding module is faulty. System-level fault detection is integrated into the application layer. The application layer collects data from the functional modules of the functional layer and uses multi-source information analysis to locate the faulty module.

[0108] Specifically, in this exemplary embodiment, a fault diagnosis system combining local and global aspects is constructed:

[0109] (1) Module-level fault detection, rapid self-check based on its own status.

[0110] Module-level fault detection is fast, cohesive, and clearly defined in its responsibilities. This functionality is directly integrated into each software module (such as modules in the driver layer and functional layers), serving as the first line of defense for the module's own health management. Its diagnostic logic relies solely on the module's internal input, output, and status data, without depending on information from other modules. The output detection result is highly simplified, typically a single Boolean value or a predefined enumeration, such as normal or faulty. It does not diagnose the root cause of the fault; it only reports that the module has a problem. Advantages: This detection method is fast, has low overhead, and does not depend on external context. It can quickly capture and report transient faults in specific functional units, providing the system with the most basic fault perception capability.

[0111] Taking the SCI module as an example, the SCI communication module integrates monitoring of multiple sub-functions. It detects hardware-reported errors such as receive buffer overflow, frame errors, parity errors, or transmit completion timeouts by querying the MCU's SCI hardware status register. Once any such hardware-indicated anomaly is detected, the module-level fault detection logic immediately sets the entire SCI module to a fault state. This is a very direct and reliable low-level fault detection method.

[0112] (2) System-level fault detection is based on intelligent diagnosis through information fusion.

[0113] System-level fault detection enables comprehensive analysis, cross-validation, and precise location; this function is typically integrated into the application layer. Detection basis: It collects and correlates data from multiple modules in the functional layer, performing multi-source information fusion and analysis. Output results: The output is no longer a simple yes / no, but can pinpoint the specific faulty module and even determine the fault type. For example, the output might indicate that the displacement sensor data acquisition module's data is unreliable or that the motor's A-phase drive circuit is suspected of being open-circuited.

[0114] Taking the feedback acquisition module as an example, when it is found that the data collected by the displacement sensor is constantly changing, the result is judged based solely on the displacement sensor data. By combining whether the Hall sensor is commutating, if the Hall sensor is not commutating, it can be determined that the data acquisition of the displacement sensor is abnormal. If the commutation direction is the same as the displacement change, it can be determined that the data acquisition of the displacement sensor is normal.

[0115] In summary, in this exemplary embodiment, module-level fault detection and system-level fault detection complement each other, forming a defense-in-depth system that can quickly respond to hard faults and intelligently diagnose soft and latent faults, greatly improving the overall reliability and fault maintainability of aerospace servo systems.

[0116] More preferably, in an exemplary embodiment, in step S3, the fault handling module performs reset recovery, hot switching, fault-tolerant operation, and shutdown on the monitored module according to the fault judgment result, including:

[0117] The fault handling module takes targeted fault handling measures based on the fault detection and location results; wherein, the fault handling measures include:

[0118] Module reset refers to the hardware reset of driver modules in the driver layer and functional modules in the functional layer that have actual physical devices and are capable of being reset. When a corresponding module fails, a hardware reset is performed on that module. For example, if no messages are received from the host computer for an extended period and the SCI module in the driver layer is confirmed to be faulty, the SCI module is reset, and after the reset, the module is assumed to be normal. Failures in these modules often stem from transient abnormal states of the hardware interface (such as bus lock-up, buffer overflow, or register deadlock). A software-level reset command is equivalent to restarting the hardware or its driver logic, effectively clearing these transient states and restoring it to a known initial healthy state. This is a cost-effective and fast preferred recovery solution.

[0119] Module hot-switching is implemented for functional modules at the functional layer (which do not have actual physical devices) and application modules at the application layer. When a corresponding module fails, its importance level is determined. If it includes core critical programs such as communication processing, motor drive, and control, a backup module is activated. The backup module has the same functionality as the original module; however, while the backup module has the same functionality, its implementation logic and input / output may differ. The switching process is completed in a very short time, with minimal impact on the overall system functionality, achieving seamless fault recovery and greatly improving system availability and task continuity.

[0120] "Operation with fault tolerance" refers to the operation of driver modules in the driver layer, functional modules in the functional layer, and application modules in the application layer. If a corresponding module malfunctions, the core functions of the system remain unaffected, and operation continues despite the fault. Taking a linear brushless DC servo system as an example, when a displacement sensor malfunction is detected, the output displacement can be calculated using Hall effect sensors. Therefore, the displacement sensor module continues operation with fault tolerance. Once the displacement sensor is detected to be functioning normally again, the output displacement is directly acquired by the sensor. In other words, the system does not immediately attempt to restore or switch to the faulty module but allows it to exist with the fault while simultaneously activating backup solutions to maintain system operation.

[0121] Shutdown, applicable to driver modules in the driver layer, functional modules in the functional layer, and application modules in the application layer, occurs when other modules are unable to support the system in fulfilling its minimum core functions after a failure. Shutdown causes the servo system to cease operation or switch to redundancy. Its primary goal is to prevent the accident from escalating and minimize losses.

[0122] These four fault handling measures together constitute a layered and comprehensive defense-in-depth system. Based on the severity of the fault and the system's redundancy, they dynamically and intelligently maintain the system's stability and security, progressing from attempted repair to seamless takeover, then to degradation tolerance, and finally to safe shutdown.

[0123] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. An aerospace servo system software framework control method with high reliability, characterized in that: The method comprises the following steps: S1: establishing a to-be-monitored module corresponding to each function of an aerospace servo system software framework, comprising: dividing the servo system into a driver layer, a function layer, and an application layer, and the to-be-monitored module comprises a driver module of the driver layer, a function module of the function layer, and an application module of the application layer; wherein the driver module of the driver layer is used to connect the hardware and the function layer and the application layer, isolate hardware differences, and provide a standardized interface; the function module of the function layer is the smallest module for implementing each function of the servo system, and if there is an actual physical device, the function module is divided according to the independent physical device, and the driver module of the driver layer is called according to actual needs, and if there is no actual physical device, the function module is divided according to independent functions; the application module of the application layer is divided according to the implementation of user requirements, and the function module of the function layer is called according to actual needs; S2: a fault judgment module judges the state of the to-be-monitored module; S3: a fault handling module executes reset recovery, hot switching, operation with fault, and shutdown on the to-be-monitored module according to the result of fault judgment, comprising: the fault handling module takes targeted fault handling measures according to the fault detection result and the positioning result; wherein the fault handling measures comprise: module reset, for the driver module of the driver layer and the function module of the function layer with an actual physical device and capable of reset, when a fault occurs in the corresponding module, hardware reset is performed on the corresponding module; module hot switching, for the function module of the function layer without an actual physical device and the application module of the application layer, when a fault occurs in the corresponding module, the importance level of the corresponding module is judged, if the corresponding module is a core and key program including communication processing, motor driving, and control, a backup module is started, and the backup module has the same function as the original module; operation with fault, for the driver module of the driver layer, the function module of the function layer, and the application module of the application layer, when a fault occurs in the corresponding module, the system core function is not affected, and the system continues to operate with fault; shutdown, for the driver module of the driver layer, the function module of the function layer, and the application module of the application layer, when a fault occurs in the corresponding module, other modules cannot support the system to meet the minimum core function, and the system is shut down to stop the servo system from moving or switching to a backup. In step S1, the establishment of the to-be-monitored module corresponding to each function of the aerospace servo system software framework further comprises:

2. The control method of the aerospace servo system software framework with high reliability according to claim 1, characterized in that: adding a driver layer data pool, a function layer data pool, and an application layer data pool, the function layer uses a pointer to call data of the driver layer data pool, and the application layer uses a pointer to call data of the function layer data pool. For the driver layer, each independent driver layer module is divided according to peripherals, and the running depends on a master control chip; 3. The control method of claim 2, wherein: the driver layer selects a corresponding driver layer module according to the requirement of the function layer; module packaging is implemented on the basis of a standard library or a HAL library provided by a chip manufacturer; the module packaging comprises establishing a data structure body and establishing a function interface. For the function layer, the function layer module packaging is implemented as follows: a data structure body is established, and if the driver layer needs to be used, a pointer is used to take data in the driver layer data pool; a function interface is established.

4. The control method of claim 2, wherein: ​ 5. The control method of claim 2, wherein: For the application layer, the application layer is used to connect various functional layer modules to constitute the required functions of the system, and the application layer module selects the corresponding functional module according to the actual application requirement, and uses a pointer to obtain data in the functional module data pool.

6. The control method of claim 5, wherein: The method further comprises an initialization step between step S1 and step S2: S1': After power-on, the application layer configures all parameters of the data pool by default data or data read from other storage modules, initializes the corresponding modules including the application layer, the functional layer and the driving layer according to the parameters in the data pool, and then enters a while loop, wherein the modules in the loop include the communication processing module, the fault judgment module in step S2 and the fault processing module in step S3.

7. The control method of claim 2, wherein: In step S2, the fault judgment module judges the state of the to-be-monitored module, including: The fault detection is divided into module-level fault detection and system-level fault detection; wherein the module-level fault detection is integrated in the driving module of each driving layer and the functional module of the functional layer, the basis of the module-level fault detection only depends on the internal data of the corresponding module, and the detection result only needs to output whether the corresponding module is faulty; the system-level fault detection is integrated in the application layer, and the application layer collects the data of the functional module of the functional layer, analyzes and locates the fault module through multi-source information.

Images