Health management architecture and management method based on IPMI (Intelligent Platform Management Interface)
Through the IPMI-based hierarchical health management architecture, the problem of chain reaction of avionics products is solved, the hierarchical design and wide applicability of health management are achieved, and the maintenance and fault positioning efficiency of avionics products are improved.
Patent Information
- Application Number
- CN202411779856.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-05
- Publication Date
- 2025-04-22
AI Technical Summary
The existing technology is difficult to effectively solve the chain reaction of avionics products under the trend of integration and integration, resulting in the system being unable to operate normally and it is difficult to maintain and locate faults on a daily basis.
Adopting a health management architecture based on IPMI, it is designed in a hierarchical and hierarchical manner, including a system health management unit, a regional health management unit and a health management unit. It is interconnected through a unified interface, monitors component status and evaluates the overall health status, and uses the health management unit to make fault judgments and status evaluations.
It realizes the hierarchical hierarchy of the health management design process of avionics products, decouples health management and specific business components, expands the scope of application and covers product types, and improves the practicality and promotion value of the design.
Smart Images
Figure CN119862082A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of aviation electronics technology, and in particular relates to an IPMI-based health management architecture and management method. Background Art
[0002] As the integration of aviation products becomes increasingly high, not only are different parts of the same unit interrelated and tightly coupled, but there is also a close connection between different units. Failure is an unavoidable state in the working process of the product. One failure may cause a series of chain reactions, resulting in the failure of the entire unit or even the entire system to operate normally, which brings great challenges to the daily maintenance of the product and the subsequent troubleshooting and location process. In the face of the development trend of informatization and intelligence of avionics products and the requirements under complex tasks, simply sensing whether a fault has occurred can no longer meet the use requirements of avionics products. Designers need to evaluate the health status of the product and prompt users whether the avionics product can meet the next use scenario. Therefore, it is necessary to build a general health management architecture for the failure characteristics of avionics products in different functional scenarios and levels, and realize health management assessment at the regional level or even the whole aircraft level, which is a necessary means to cope with the health monitoring and health management of avionics systems under the trend of integration and integration. Summary of the invention
[0003] The purpose of the present invention is to provide a health management architecture and management method based on IPMI, expand the scope of application of the architecture, standardize the architecture design method, and improve the level of health management architecture design.
[0004] The technical solution of the present invention:
[0005] An IPMI-based health management architecture includes: a system health management unit, a regional health management unit, and a health management unit;
[0006] A regional health management unit runs on each common processing component;
[0007] A health management unit runs on each of the other monitored components;
[0008] A regional health management unit is connected to multiple health management units; all regional health management units are connected to the system health management unit;
[0009] The health management unit is used to monitor the status of its corresponding component and send the monitoring data to the regional health management unit;
[0010] The regional health management unit is used to detect the status of the corresponding general processing component and control the health management units connected to it; and evaluate the status of its control area;
[0011] The system health management unit is used to collect the status of all regional health management units to evaluate the overall status.
[0012] Furthermore, the monitored components include: one or more of a data processing component, a graphics processing component, a power management component, a network switching component, a fan component, a data storage component, and a graphics generation component.
[0013] Furthermore, the health management unit running on the power management component is also used to monitor the power supply power, voltage, and current of all components.
[0014] Furthermore, if the monitored components include fan components, the regional health management unit connected thereto is also used to monitor the temperature data of all components and control the rotation speed of the fan according to the temperature data.
[0015] Furthermore, the regional health management unit and the health management unit are configured according to the configuration file to adapt to different monitored components.
[0016] Furthermore, the regional health management unit and the health management unit configure their own interfaces, fault judgment thresholds, fault filtering parameters, evaluation logic, communication protocols and recording formats according to the configuration files.
[0017] An IPMI-based health management method is implemented based on the architecture and includes the following steps:
[0018] Step 1: The system health management unit enables the regional health management unit and the health management unit according to the configuration;
[0019] Step 2: The enabled regional health management unit and health management unit select all interfaces that need to work according to the configuration file;
[0020] Step 3: The enabled regional health management unit and health management unit collect data through the selected interface;
[0021] Step 4: The enabled regional health management unit and health management unit temporarily store the collected data;
[0022] Step 5: The enabled regional health management unit and the health management unit perform fault judgment on the temporarily stored data according to the fault judgment threshold. If the fault is established, proceed to the next step, otherwise return to step 3;
[0023] Step 6: Fault filtering is performed according to the fault filtering parameters. If the fault filtering result is that a fault has occurred, the fault information is reported and the next step is entered; otherwise, the fault is filtered out and the process returns to step 3.
[0024] Step 7: The regional health management unit and the system health management unit respectively determine the health status of their respective control areas.
[0025] Further, the fault filtering method is as follows:
[0026] By reading the fault filtering parameters of the configuration file and the accumulated number of fault occurrences, it is determined whether the interface corresponding to the detection item has a fault. If so, the fault status is reported to the health status evaluation logic inside the health management unit to evaluate the health status of the component; if not, the external signal of the next cycle is collected and the number of fault occurrences is cleared.
[0027] Furthermore, the regional health management unit determines the health status of its own control area as follows:
[0028] The regional health management unit collects the health status of the health management units in this region (i.e., the fault data reporting information and fault record information of the health management units in this region), and evaluates the health status of this region based on the health status of the components it is responsible for and the evaluation logic in the configuration file.
[0029] Furthermore, the system health management unit determines the overall health status of the platform as follows:
[0030] The system health management unit collects the regional health status reported by the regional health management unit of this platform, and evaluates the health status of this system according to the evaluation logic in the configuration file.
[0031] Beneficial effects of the present invention:
[0032] The present invention provides a health management architecture and management method based on IPMI, which makes the health management design process hierarchical and graded. Through a reusable platform design, it effectively solves the problem of high complexity in the health management design of avionics products, realizes the decoupling of health management design from specific business components, has a wide range of use, covers a wide range of product types, and has strong practical and promotion value. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] Figure 1 Schematic diagram of the composition of a typical product platform for avionics systems.
[0034] Figure 2 Schematic diagram of the division of labor at each level of health management.
[0035] Figure 3 Schematic diagram of the unit detection interface.
[0036] Figure 4 Schematic diagram of health monitoring configuration.
[0037] Figure 5 Schematic diagram of the health management data collection and judgment process. DETAILED DESCRIPTION
[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0039] (1) Design of scalable health management hardware platform based on IPMI
[0040] The health management architecture hardware of the present invention adopts an expandable hardware platform based on the VPX standard. The units that undertake the health management function are divided into three levels: system health management unit, regional health management unit and health management unit. The units at each level undertake different functions, and the regional health management unit and the health management unit are interconnected with each other using a unified interface. Each regional health management unit and health management unit monitors the health status of the component in which it is located. The hardware platform also has the following functions:
[0041] 1) Component power monitoring
[0042] 2) Component power management
[0043] 3) Platform fan control
[0044] 4) Component health status monitoring
[0045] 5) Regional health status monitoring
[0046] 6) Platform health status monitoring
[0047] 7) Component online and offline management
[0048] (2) Configurable health monitoring design
[0049] The health management unit of the present invention is implemented using a unified health management chip. Each unit has the same detection interface and can be flexibly configured according to the different components to be monitored. When the health management unit is working, it reads its own configuration file and performs the following configuration:
[0050] 1) Data input interface configuration
[0051] 2) Judgment threshold configuration
[0052] 3) Filter parameter configuration
[0053] 4) Evaluate the logical configuration
[0054] 5) Communication protocol configuration
[0055] 6) Record format configuration
[0056] In order to better understand the present invention, the technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments.
[0057] Figure 1 Schematic diagram of the composition of a typical health management hardware platform for avionics products. The figure selects the main component types of typical avionics products and briefly illustrates the avionics products. For typical avionics system products, the main components include power management components, data processing components, network switching components, general processing components, and for display and warning systems, graphics processing components. In order to ensure that the working status of each component can be obtained, each component contains a health management unit to collect component working parameters and perform health management.
[0058] The health management unit is mainly divided into three levels, from high to low, namely system health management unit, regional health management unit and health management unit. The health management unit is responsible for collecting the working parameters of its own components and evaluating the health status of its own components; in addition to collecting parameters and evaluating status, the regional health management unit also manages the health management units connected to it, controls their enabling and operation, collects their health status, and evaluates the health status of the area it is responsible for; the system health management unit is not responsible for collecting the working parameters of the components, but only collects the health status of the health management units in each region and evaluates the health status of the platform.
[0059] Figure 2 Schematic diagram of the division of labor at each level of health management. The figure describes in detail the main functions of different units at the three levels.
[0060] As the most widely distributed health management unit on the platform, the health management unit is at the bottom layer of the architecture and is responsible for monitoring the health status of its own components. If it is the health management unit of the power management component, it will also be responsible for the power management and power monitoring of all components.
[0061] As the second-layer unit of the architecture, the regional health management unit is responsible for monitoring the health status of its own components on the one hand, and the health status of all components of the health management units connected to this unit on the other hand. If the platform has a fan, it is also responsible for controlling the fan speed of the platform. The regional health management unit will adjust the fan speed based on the temperature data collected from each component to maintain the temperature of the entire platform.
[0062] As the highest-level unit of the architecture, the system health management unit aggregates the health management data of all components in the platform, comprehensively evaluates the health status of each component, and manages each component online and offline based on the health status. It then synthesizes the overall health status of the platform and, combined with the platform's own usage scenarios, evaluates whether the platform's current health status can meet current usage requirements and obtains the task integrity assessment results.
[0063] Figure 3 Schematic diagram of the unit detection interface. The figure describes the data input interface of the health management unit and the types of monitored working parameters. The basic health management data of avionics products can be summarized as bus data, power supply characteristics, temperature acquisition, discrete quantity monitoring, analog quantity monitoring, heartbeat acquisition, fan control and other basic data. According to the characteristics of the operating unit represented by each basic data, the characteristic signals used to characterize each operating unit can be further summarized as analog signal quantities, such as voltage, current, impedance characteristics, etc.; digital signals, such as bus communication and data storage; discrete quantity signals, such as control variables, etc.
[0064] Figure 4 Schematic diagram of the health management unit configuration process. The figure shows the configurable avionics system health management process in the form of a health management unit. From the perspective of the diagram, it can be divided into six parts, which are described below.
[0065] based on Figure 1The schematic diagram of the composition of a typical avionics product is shown in the figure. According to the basic business function unit, the basic composition of avionics products can be summarized as power management components, data processing components, network switching components, general processing components, graphics processing components and other components. According to the operation mode of each basic component, the characteristic signals used to characterize each basic component can be further summarized as basic health management data, which can be summarized as basic data such as bus data, power characteristics, temperature acquisition, discrete quantity monitoring, analog quantity monitoring, heartbeat acquisition, fan control, etc. Therefore, the health management unit needs to realize the acquisition of each interface data according to the interface type, such as the acquisition of analog signal quantity, discrete quantity data acquisition, etc., that is, the content of part ② in the figure. This part is the data input interface configuration, and the corresponding processing resources cover the signal transceiver interface including but not limited to SPI, Localbus, PCIe, RS422 and other connection forms. The use of these interface processing logics is realized through the definition of configuration file ①. The input data is processed by the configured input interface, and when the status data is converted into internal data, it will be uniformly used in fault judgment ③. Before data detection, it is necessary to judge the data according to the judgment threshold configuration defined in the configuration file ① (including tolerance upper limit, upper limit, threshold, cycle, time difference and other information). After the fault judgment logic ③ completes the fault judgment of all input data, the final result will be fault filtered ④ according to the filtering conditions of each detection object defined in the configuration file ① to filter out false alarms and false positives. After completing the fault filtering, according to the fault mode represented by each input fault data and the corresponding component hardware design, the component health status evaluation ⑤ is completed, and the evaluation results and initial fault information will be reported through the data output interface ⑥, and finally passed to the superior health management unit. At the same time, the initial fault information of the fault will also be recorded in the non-volatile memory or the on-board data recording unit to support field fault isolation.
[0066] Figure 5 Schematic diagram of the health management data collection and judgment process. The figure describes the data collection and fault judgment process of the health management unit.
[0067] (1) Health management unit enablement
[0068] Since different hardware platforms of avionics products have different configurations, and the same platform may also control the online and offline of different components in different usage scenarios, in order to avoid false alarms or false alarms, the components and platforms need to provide enable control signals based on the actual characteristics of the product, such as power-on sequence, flight phase, etc. The health management unit starts to collect the signals sent by the detected components only after receiving the enable signal.
[0069] (2) Find the configuration file
[0070] The health management unit collects the signal of the monitored component and searches whether the interface definition of the collected signal is in the interface specified in the configuration file according to the interface definition and identification of the collected signal. If not, continue to collect external signals according to step (2). If yes, proceed to the next step.
[0071] (3) Data collection
[0072] Read the data of the health management data input interface according to the interface defined in the configuration file.
[0073] (4) Data Temporary Storage
[0074] The read health management data is temporarily stored for subsequent fault diagnosis.
[0075] (5) Read the configuration parameters of the fault judgment conditions of the detection items
[0076] According to the definition of the configuration file, read the parameters used by the detection item to execute the fault judgment condition.
[0077] (6) Execute the fault judgment logic of the detection item
[0078] The fault threshold parameters configured for all detected components are brought into the fault judgment logic, and the fault judgment is performed to determine whether the fault judgment conditions are met. If not, the fault is not established, and the external signal is collected according to step (2). If established, proceed to the next step.
[0079] (7) Read fault filtering parameters
[0080] In order to avoid false alarms and misalarms caused by accidental faults, a single fault will not be reported directly, but the number of faults will be accumulated and the fault filtering parameters of the configuration file will be read to facilitate fault filtering of the judgment results.
[0081] (8) Fault filtering judgment
[0082] By reading the fault filtering parameters of the configuration file and the accumulated number of fault occurrences, it is determined whether the interface corresponding to the detection item has a fault. If yes, proceed to the next step; if not, execute step (2) to continue collecting the next cycle of external signals and clear the number of fault occurrences.
[0083] (9) Health status assessment
[0084] After the fault is filtered by the health management unit, it is confirmed that the fault has occurred, and the fault status is reported to the health status assessment logic inside the health management unit to assess the health status of the component, and then execute subsequent data reporting, fault recording and other links.
[0085] Embodiment 1
[0086] For data processing components, design health management according to the above steps.
[0087] Step 1: After receiving the system health management unit enable signal, the health management unit starts to collect the signal sent by the detected data processing component.
[0088] Step 2: The health management unit collects the signal of the data processing component, and according to the interface definition and identification of the collected signal, finds whether the interface definition of the collected signal is in the interface specified in the configuration file. If not, continue to collect other signals. If yes, proceed to the next step.
[0089] Step 3: Read the data of the health management data input interface according to the interface defined in the configuration file. For the data processing component, the interfaces that need to be read are: bus data, discrete quantity monitoring, business equipment monitoring, heartbeat monitoring, and temperature collection.
[0090] Step 4: Temporarily store the read health management data for subsequent fault diagnosis.
[0091] Step 5: According to the definition of the configuration file, read the parameters used by the detection items to execute the fault judgment conditions. The parameters of the bus data interface are that the communication bit error rate does not exceed 10 to the negative sixth power, the parameters of the discrete quantity monitoring interface are always high, the parameters of the business equipment monitoring interface are that the specific register value range is 0-1023, the parameters of the heartbeat monitoring are that the number of heartbeats increases by 1 after each heartbeat cycle, and the parameter of the temperature collection is 80 degrees Celsius.
[0092] Step 6: Bring the fault threshold parameters configured by the data processing component into the fault judgment logic, execute the fault judgment, and determine whether the fault judgment conditions are met. If not, the fault is not established, and continue to collect external signals according to step (2). If established, proceed to the next step.
[0093] Step 7: In order to avoid false alarms and false alarms caused by accidental failures, the data processing component will not report a single failure directly, but will accumulate the number of failures and read the fault filtering parameters of the configuration file to facilitate fault filtering of the judgment results. The fault filtering parameter of the data processing component is 3, that is, when three consecutive detections are all faulty, the health management unit considers that the data processing component has failed.
[0094] Step 8: By reading the fault filtering parameters of the configuration file and the accumulated number of fault occurrences, determine whether the interface corresponding to the detection item has a fault. If yes, proceed to the next step; if not, execute step (2) to continue collecting the next cycle of external signals and clear the number of fault occurrences.
[0095] Step 9: After the fault is filtered by the health management unit, it is confirmed that the fault has occurred, and the fault status is reported to the health status evaluation logic inside the health management unit to evaluate the health status of the data processing component. After the evaluation results are completed, the fault data and fault record information are reported to the regional health management unit.
[0096] The evaluation logic is as follows:
[0097] 1. If the bus data interface fails, the execution of some tasks will be affected, and the current health status needs to be reported, indicating that some tasks cannot be executed;
[0098] 2. If the discrete quantity monitoring interface fails, it will affect the execution of all tasks, and it is necessary to report the current health status and cannot execute all tasks;
[0099] 3. If a business equipment monitoring interface fails, you need to record and request to shut down the power of the data processing component and then power it on again;
[0100] 4. If the heartbeat monitoring interface fails, you need to record and request a reset component;
[0101] 5. If the temperature collection interface fails, you need to record and request to increase the speed of a single fan component.
[0102] Embodiment 2
[0103] For network switching components, design health management according to the above steps.
[0104] Step 1: After receiving the system health management unit enable signal, the health management unit starts to collect signals sent by the detected network switching component.
[0105] Step 2: The health management unit collects the signal of the network switching component, and according to the interface definition and identification of the collected signal, finds whether the interface definition of the collected signal is in the interface specified in the configuration file. If not, continue to collect other signals. If yes, proceed to the next step.
[0106] Step 3: Read the data of the health management data input interface according to the interface defined in the configuration file. For the network switching component, the interfaces that need to be read are: bus data, analog quantity monitoring, business equipment monitoring, power supply characteristics, and temperature collection.
[0107] Step 4: Temporarily store the read health management data for subsequent fault diagnosis.
[0108] Step 5: According to the definition of the configuration file, read the parameters used to execute the fault judgment conditions of the detection items. The parameters of the bus data interface are that the communication bit error rate does not exceed 10 to the negative sixth power, the parameters of the analog monitoring interface are in the range of -15V to +15V, the parameters of the power characteristic interface are that the voltage value is between 3.0V and 3.6V, the parameters of the heartbeat monitoring are that the number of heartbeats increases by 1 for each heartbeat cycle, and the parameter of the temperature acquisition is 100 degrees Celsius.
[0109] Step 6: Bring the fault threshold parameters configured by the network switching component into the fault judgment logic, execute the fault judgment, and determine whether the fault judgment conditions are met. If not, the fault is not established, and continue to collect external signals according to step (2). If established, proceed to the next step.
[0110] Step 7: In order to avoid false alarms and false alarms caused by accidental failures, a single failure of the network switching component will not be reported directly, but the number of failures will be accumulated, and the fault filtering parameters of the configuration file will be read to facilitate fault filtering of the judgment results. The fault filtering parameter of the network switching component is 5, that is, when there are 5 consecutive failures, the health management unit considers that the network switching component has failed.
[0111] Step 8: By reading the fault filtering parameters of the configuration file and the accumulated number of fault occurrences, determine whether the interface corresponding to the detection item has a fault. If yes, proceed to the next step; if not, execute step (2) to continue collecting the next cycle of external signals and clear the number of fault occurrences.
[0112] Step 9: After the fault is filtered by the health management unit, it is confirmed that the fault has occurred, and the fault status is reported to the health status evaluation logic inside the health management unit to evaluate the health status of the network switching component. After the evaluation results are completed, the fault data and fault record information are reported to the regional health management unit.
[0113] The evaluation logic is as follows:
[0114] 1. If a bus data interface fails, it will affect the execution of a certain task, and it is necessary to report the current health status and cannot execute a certain task;
[0115] 2. If the analog quantity monitoring interface fails, it will affect the execution of certain tasks, and it is necessary to report the current health status and cannot execute certain tasks;
[0116] 3. If the power characteristic interface fails, you need to record and report the task and then repair the component after the task is completed;
[0117] 4. If the heartbeat monitoring interface fails, you need to record and request a reset component;
[0118] 5. If the temperature collection interface fails, you need to record and request to increase the speed of the two fan components.
[0119] The above is only a specific embodiment of the present invention, and the present invention is described in detail. The unexplained part is a conventional technology. However, the protection scope of the present invention is not limited to this. Any changes or substitutions that can be easily thought of by any technician familiar with the technical field within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. The protection scope of the present invention shall be based on the protection scope of the claims.
Claims
1. A health management architecture based on IPMI, characterized by: The architecture includes: a system health management unit, a regional health management unit, and a health management unit; A regional health management unit runs on each common processing component; A health management unit runs on each of the other monitored components; A regional health management unit is connected to multiple health management units; all regional health management units are connected to the system health management unit; The health management unit is used to monitor the status of its corresponding component and send the monitoring data to the regional health management unit; The regional health management unit is used to detect the status of the corresponding general processing component and control the health management units connected to it; and evaluate the status of its control area; The system health management unit is used to collect the status of all regional health management units to evaluate the overall status.
2. The architecture according to claim 1, characterized in that: The monitored components include: one or more of a data processing component, a graphics processing component, a power management component, a network switching component, a fan component, and a data storage component.
3. The architecture according to claim 2, characterized in that: The health management unit running on the power management component is also used to monitor the power supply power, voltage, current, temperature, and power-on times of all components.
4. The architecture according to claim 3, characterized in that: If the monitored components include fan components, the regional health management unit connected thereto is also used to monitor the temperature data of all components and control the speed of the fan according to the temperature data.
5. The architecture according to claim 4, characterized in that: The regional health management unit and the health management unit are configured according to the configuration files to adapt to different monitored components.
6. The architecture according to claim 5, characterized in that: The regional health management unit and the health management unit configure their own interfaces, fault judgment thresholds, fault filtering parameters, evaluation logic, communication protocols and recording formats according to the configuration files.
7. A health management method based on IPMI, implemented based on the architecture of any of the preceding claims, characterized in that: The following steps are involved: Step 1: The system health management unit enables the regional health management unit and the health management unit according to the configuration; Step 2: The enabled regional health management unit and health management unit select all interfaces that need to work according to the configuration file; Step 3: The enabled regional health management unit and health management unit collect data through the selected interface; Step 4: The enabled regional health management unit and health management unit temporarily store the collected data; Step 5: The enabled regional health management unit and the health management unit perform fault judgment on the temporarily stored data according to the fault judgment threshold. If the fault is established, proceed to the next step, otherwise return to step 3; Step 6: Filter the faults according to the fault filtering parameters. If the fault filtering result is a real fault, report the fault information and proceed to the next step. Otherwise, filter out the fault and return to step 3; Step 7: The regional health management unit and the system health management unit respectively determine the health status of their respective control areas.
8. The architecture according to claim 7, characterized in that: Fault filtering methods are as follows: By reading the fault filtering parameters of the configuration file and the accumulated number of fault occurrences, it is determined whether the interface corresponding to the detection item has a fault. If so, the fault status is reported to the health status evaluation logic inside the health management unit to evaluate the health status of the component; if not, the external signal of the next cycle will continue to be collected and the number of fault occurrences will be cleared.
9. The architecture according to claim 8, characterized in that: The process by which the regional health management unit determines the health status of the area it controls is as follows: The regional health management unit collects the health status of the health management units in the region, including the fault data reporting information and fault record information of the health management units in the region, and evaluates the health status of the region based on the health status of the components it is responsible for and the evaluation logic in the configuration file.
10. The architecture according to claim 8, characterized in that: The system health management unit determines the overall health status of the platform as follows: The system health management unit collects the regional health status reported by the regional health management unit of this platform, and evaluates the health status of this system according to the evaluation logic in the configuration file.