Safety management method for infrastructure of integrated modular avionics system

Abstract

The invention provides a comprehensive modular avionics system infrastructure safety management method, which relates to the technical field of comprehensive avionics, and comprises the following steps: respectively electrifying an instance 1 and an instance 2 for infrastructure health management and performing start arbitration, and determining a master instance and a slave instance through the start arbitration, the instance 1 and the instance 2 determine the current state of the opposite side by acquiring a heartbeat message published by the opposite side; the master instance and the slave instance are arbitrated after being started in real time so as to determine whether to perform master-slave state switching; and the slave instance reports the current state of the slave instance to the master instance by issuing heartbeat information, and the master instance reports the functional conditions of all infrastructures in the whole cabinet to a health management platform. According to the invention, through switching of the master instance and the slave instance in the abnormal scene, it is ensured that robust and guaranteed infrastructure health management services are provided for a platform-level health management function.

Description

Technical Field

[0001] The present invention relates to the field of integrated avionics technology, and in particular to a method for safety management of basic equipment of an integrated modular avionics system. Background Art

[0002] The avionics system is a safety-critical system. The safety and reliability of avionics software are related to the safety of the entire aircraft. Based on this consideration, the health management function of the basic equipment in the cabinet, including the power management module, fan and valve, should consider how to ensure the stable provision of robust health management services when some functions are lost. This is crucial to the safety of the entire avionics system. Therefore, it is necessary to solve the problem of hot backup of basic equipment health management in the integrated modular avionics system to ensure the provision of robust and guaranteed basic equipment health management services for the platform-level health management function. Summary of the invention

[0003] In view of this, an embodiment of the present application provides a comprehensive modular avionics system basic equipment safety management method, which ensures the provision of robust and guaranteed basic equipment health management services for platform-level health management functions through switching between master and slave instances in abnormal scenarios.

[0004] The embodiment of the present application provides the following technical solution: a comprehensive modular avionics system basic equipment safety management method, including:

[0005] Instance 1 and instance 2 for basic equipment health management are powered on and start arbitration respectively, and a master instance and a slave instance are determined by the start arbitration, wherein instance 1 and instance 2 determine each other's current state by obtaining heartbeat messages published by each other;

[0006] The master instance and the slave instance perform post-startup arbitration in real time to determine whether to perform master-slave status switching;

[0007] The slave instance reports its current status to the master instance by publishing heartbeat information, and the master instance reports the functional status of all basic devices in the entire cabinet to the health management platform;

[0008] The process of starting arbitration includes: if the instance 1 determines that the current state of the instance 2 is inactive or activated as a slave instance through the heartbeat message published by the instance 2, the instance 1 sets its own state to the master instance; if the instance 2 determines that the current state of the instance 1 is inactive or activated as a slave instance through the heartbeat message published by the instance 1, the instance 2 sets its own state to the master instance;

[0009] The post-startup arbitration process includes: when the master instance receives a state switching notification from the slave instance, the master instance judges its own current functional state, and determines whether to agree to the state switching according to the judgment result; if agreed, the master instance sets its own state to slave waiting, and notifies the slave instance to switch the state, and when the master instance receives a switching completion notification sent by the slave instance, it sets its own state to the slave instance; when the slave instance receives a state switching notification from the master instance, the slave instance judges its own current functional state to determine whether it has the conditions for switching to the master instance, and if so, switches its own state to the master instance.

[0010] According to an embodiment of the present application, the process of initiating arbitration also includes: if both instance 1 and instance 2 are in an activated state, and instance 2 is activated as a master instance, instance 1 sets its own state to a slave instance.

[0011] According to an embodiment of the present application, the process of initiating arbitration also includes: if both instance 1 and instance 2 are in an activated state, and instance 1 is activated as a master instance, instance 2 sets its own state to a slave instance.

[0012] According to an embodiment of the present application, the post-startup arbitration process further includes: if both the instance 1 and the instance 2 are slave instances, the instance 1 sets its own status to the master instance.

[0013] According to an embodiment of the present application, the post-startup arbitration process further includes: if both the instance 1 and the instance 2 are master instances, the instance 2 sets its own status to a slave instance.

[0014] According to an embodiment of the present application, the post-startup arbitration process also includes: when the main power supply of the master instance is lost, the master instance sends the state switching notification to the slave instance, and the state switching notification includes the time interval of the state switching.

[0015] According to one embodiment of the present application, the post-startup arbitration process also includes: the slave instance makes a judgment based on the heartbeat message published by the master instance, and if the current functional state of the slave instance itself is better than the current functional state of the master instance, the slave instance sends the state switching notification to the master instance.

[0016] According to one embodiment of the present application, the post-startup arbitration process also includes: when the slave instance receives a status switching notification from the master instance, the slave instance judges its current functional status to determine whether it has the conditions to switch to the master instance; if so, the slave instance notifies the master instance through a heartbeat message that it can currently switch to the master instance; upon receiving a switching consent message sent by the master instance, the slave instance switches its status to the master instance and sends a switching completion notification to the master instance.

[0017] According to one embodiment of the present application, the post-startup arbitration process also includes: when the master instance receives a message sent by the slave instance that it can currently switch to the master instance, the master instance sets its own state to slave waiting, and when the switching completion notification sent by the slave instance is received, the master instance switches its own state from slave waiting to slave instance.

[0018] Compared with the prior art, the at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0019] 1. The redundancy management of the master and slave instances in the embodiment of the present invention ensures that the IMA platform has a robust basic equipment health management function in abnormal scenarios, and the switching process of the master and slave instances is transparent and invisible to external users of the platform, and cannot be perceived by external users, which is consistent with when the two instances are completely normal, and can provide highly reliable services.

[0020] 2. In the embodiment of the present invention, the master-slave arbitration of the power-on process only considers whether another instance is started or its status after startup, which can ensure that the general computing module starts quickly and provide basic equipment health management functions.

[0021] 3. After the startup is completed in the embodiment of the present invention, the master-slave arbitration process based on specific conditions takes into account abnormal situations occurring in multiple scenarios. The ultimate goal is to ensure that there is only one basic equipment health management master instance at the same time. In this way, the platform-level health management function can obtain the current status information of the entire cabinet by only receiving the cabinet periodic monitoring report information issued by the master instance. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0023] Figure 1 is a synchronization diagram of the safety management status of basic equipment of the integrated modular avionics system according to an embodiment of the present invention;

[0024] Figure 2 is a master-slave state transition diagram of Example 1 in an embodiment of the present invention;

[0025] Figure 3 is a master-slave state transition diagram of Example 2 in an embodiment of the present invention;

[0026] Figure 4 This is a flowchart of initializing master-slave arbitration in Example 1 and Example 2 in an embodiment of the present invention;

[0027] Figure 5 It is a detailed flow chart of master-slave instance state switching in an embodiment of the present invention. DETAILED DESCRIPTION

[0028] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0029] The following describes the implementation methods of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The present application can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that, in the absence of conflict, the following embodiments and the features in the embodiments can be combined with each other. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work belong to the scope of protection of the present application.

[0030] In an embodiment of the present invention, the cabinet basic equipment health management function is responsible for providing health management functions for devices that are not directly connected to the avionics data network, including power management modules PSM, fans / valves, etc. The cabinet basic equipment health management function is implemented as an application for the entire integrated modular avionics system and maintenance part. The basic equipment health management function runs as two redundant instances, which reside on two separate general computing modules in each cabinet and can access the cabinet internal communication bus. Each health management instance can publish cabinet periodic monitoring report information, but only one is expected to be used at the same time for the platform-level health management function. Based on this consideration, only the master instance publishes the cabinet periodic monitoring report to the platform-level health management function, and can communicate through the cabinet internal communication bus. When it becomes the master instance, it starts to send the cabinet periodic monitoring report. The slave instance reports its own status to the master instance through a heartbeat message. The master instance is responsible for reporting the functional status of all basic devices in the entire cabinet, including the functional status of the slave instance.

[0031] Master-slave instance information synchronization of a basic equipment health management instance according to an embodiment of the present invention Figure 1 shown.

[0032] The two health management instances synchronize by publishing heartbeat messages and monitoring the messages published by the other instance. The redundancy information in the heartbeat message is used to determine the master instance of the infrastructure health management.

[0033] Each instance has four states: power up state, slave instance, master instance, slave waiting (master instance waiting to switch to slave instance), and these four states should be reflected in the heartbeat message. The embodiment of the present invention defines these four states as: 0 = Power Up State; 1 = Secondary State; 2 = Primary State; 3 = Secondary Pending State.

[0034] The basic equipment health management instances residing on the cabinet on one side are marked as instance 1 and instance 2. The state transition diagram of instance 1 is as follows: Figure 2 As shown, the state transition diagram of Example 2 is as follows Figure 3 shown.

[0035] like Figure 2-3 As shown, an embodiment of the present invention provides a method for safety management of basic equipment of an integrated modular avionics system, including:

[0036] Instance 1 and instance 2 for basic equipment health management are powered on and start arbitration respectively, and a master instance and a slave instance are determined by the start arbitration, wherein instance 1 and instance 2 determine each other's current state by obtaining heartbeat messages published by each other;

[0037] The master instance and the slave instance perform post-startup arbitration in real time to determine whether to perform master-slave status switching;

[0038] The slave instance reports its current status to the master instance by publishing heartbeat information, and the master instance reports the functional status of all basic devices in the entire cabinet to the health management platform;

[0039] The process of starting arbitration includes: if the instance 1 determines that the current state of the instance 2 is inactive or activated as a slave instance through the heartbeat message published by the instance 2, the instance 1 sets its own state to the master instance; if the instance 2 determines that the current state of the instance 1 is inactive or activated as a slave instance through the heartbeat message published by the instance 1, the instance 2 sets its own state to the master instance;

[0040] The post-startup arbitration process includes: when the master instance receives a state switching notification from the slave instance, the master instance judges its own current functional state, and determines whether to agree to the state switching according to the judgment result; if agreed, the master instance sets its own state to slave waiting, and notifies the slave instance to switch the state, and when the master instance receives a switching completion notification sent by the slave instance, it sets its own state to the slave instance; when the slave instance receives a state switching notification from the master instance, the slave instance judges its own current functional state to determine whether it has the conditions for switching to the master instance, and if so, switches its own state to the master instance.

[0041] The present invention is described in detail below with reference to the accompanying drawings.

[0042] In some embodiments, the power-on process is the software function startup phase. In the startup phase, the role setting process of the two CCR CE health management instances (i.e., switching between the three states of power-on state, slave instance, and master instance) is as follows:

[0043] The process of initiating arbitration includes:

[0044] Step 1: When powered on, instance 1 and instance 2 will set their respective roles to the power-on state, i.e., "PowerUp";

[0045] Step 2: Both instances will perform startup arbitration during each startup process. During the startup arbitration process, if instance 1 finds out through heartbeat messages that instance 2 is not activated or activated as a slave, instance 1 will set its role to "Primary". Conversely, if instance 2 finds out through heartbeat messages that instance 1 is not activated or activated as a slave, instance 2 will set its role to "Primary". When both instances are activated, if instance 1 is a slave instance and instance 2 is a master instance, instance 1 continues to be "Secondary" and instance 2 continues to be "Primary". The rest are processed as instance 1 being the master and instance 2 being the slave. The processing process is as follows: Figure 4 shown.

[0046] In some embodiments, the post-initiation arbitration process includes:

[0047] Step 1: The arbitration process after startup involves the judgment of internal conditions and priorities. When both instances are started, there is only one primary instance. In this case, both instances remain in their original states without any switching operation.

[0048] Step 2: When "dual master instances" occur, instance 1 remains as the master instance and instance 2 switches to the slave instance; or when "dual slave instances" occur, instance 1 switches to the master instance and instance 2 remains as the slave instance. In all other cases, master-slave transfer (the master-slave state switch described above) needs to be considered.

[0049] (1) When receiving a state switching notification from a slave instance, parse the notification content.

[0050] Step 1. If the master-slave transfer is accepted, the role switch will start, the master instance will be set to "slave waiting", and the slave instance will be notified to switch roles. Continue to wait for the role switch completion notification from the slave instance. After receiving it, the "slave waiting" must be set to "slave instance", and the entire transfer process on the master instance is completed.

[0051] Step 2. If you do not agree to the master-slave transfer, the master instance must continue to maintain the master role and the transfer process ends.

[0052] The slave instance makes a judgment based on the heartbeat message published by the master instance, and if the current functional state of the slave instance itself is better than the current functional state of the master instance, the slave instance sends the state switching notification to the master instance.

[0053] (2) From the instance side, when receiving the master-slave transfer notification from the master instance, the slave instance determines whether it has the conditions to switch to the master instance based on its own internal situation. If it has the conditions, it notifies the master instance that it can switch to the master instance. If it does not have the conditions, it notifies the master instance that it cannot switch to the master instance. After the notification is completed, it continues to wait for the message from the master instance. When receiving the role switch notification from the master instance, it needs to set the slave instance to "master instance". After the setting is completed, the latest instance role should be notified to the original master instance in time to end the transfer process. The slave instance transfer process ends here.

[0054] When the main power supply of the master instance is lost, the master instance sends the state switching notification to the slave instance, and the state switching notification includes the time interval of the state switching. Figure 5 shown.

[0055] The present invention is described in detail below in conjunction with specific embodiments.

[0056] The power-on process is the software function startup phase. During the startup phase, the role setting process of the two CCR CE health management instances (i.e., switching between the three states of power-on state, slave instance, and master instance) is as follows:

[0057] Step 1. At the beginning of startup, instance 1 and instance 2 will set their respective roles to the power-on state, i.e. "PowerUp";

[0058] Step 2. Both instances will perform startup arbitration during each startup process. During the startup arbitration process, if instance 1 finds that instance 2 is not activated or is activated as a slave, instance 1 will set its role to "Primary". Similarly, if instance 2 finds that instance 1 is not activated or is activated as a slave, instance 2 will set its role to "Primary". When both instances are in an activated state, if instance 1 is a slave instance and instance 2 is a primary instance, instance 1 continues to be "Secondary" and instance 2 continues to be "Primary". The other three cases are all processed as instance 1 being the primary and instance 2 being the slave. The processing process is as follows: Figure 4 shown.

[0059] After the startup is completed, the arbitration process based on specific conditions is considered. The difference between the arbitration process after startup and the arbitration process at startup is that the judgment of the arbitration process after startup also includes internal conditions and priorities. The initial state is the following:

[0060] The first is that instance 1 is the primary instance and instance 2 is not activated;

[0061] The second is that instance 1 is not activated and instance 2 is the primary instance;

[0062] The third type is that instance 1 is the master instance and instance 2 is the slave instance;

[0063] The fourth type is that instance 1 is the slave instance and instance 2 is the master instance;

[0064] The fifth type is that instance 1 is the main instance, and instance 2 is also the main instance.

[0065] After at least one cabinet basic equipment health management instance is started, the possible states of instance 1 and instance 2 are as shown in 1 to 4 in Table 1. During the program running, the states of 5 to 12 in Table 1 may also appear.

[0066] Table 1. Instance status of basic equipment instance 1 and instance 2 after startup.

[0067] Serial number Instance 1 Role Instance 2 Role Remark 1 Master Instance Not activated No processing required 2 Not activated Master Instance No processing required 3 Master Instance From the example No processing required 4 From the example Master Instance When instance 2 starts faster than instance 1 5 From the example Not activated Set the active slave instance to the master instance 6 Not activated From the example Set the active slave instance to the master instance 7 From the example From the example Set instance 1 as the primary instance 8 Master Instance Master Instance Set instance 2 as the slave instance 9 From waiting Master Instance During master-slave switching 10 Master Instance From waiting During master-slave switching 11 From waiting From the example During master-slave switching 12 From the example From waiting During master-slave switching

[0068] The combined analysis of state 1 and state 2 shows that only one module is activated successfully. If another module is identified to be activated, the module started first will continue to be the master instance, and the module started later will change from "not activated" to "slave". At this time, state 1 becomes state 3, and state 2 becomes state 4.

[0069] Looking at state 3 and state 4, considering the internal situation of the master instance after the startup is completed, there may be a situation where the main power is lost, and the master-slave transfer situation will occur at this time. Master-slave transfer refers to the two basic device instances voting on a master instance based on their own and the other instance's internal conditions based on specific arbitration conditions after the startup is completed. It also refers to the stage of dynamic adjustment of the master-slave roles after the startup is completed. After the master-slave transfer process, the module role enters a relatively stable state.

[0070] The master-slave transfer process involves two basic device health management function instances. Because this process is after the startup is completed, both instances have an initial state.

[0071] From the analysis of the master instance, if the current master instance loses two main power supplies, it will be powered off within 11 seconds. At this time, it is no longer suitable to report the cabinet status to the platform-level health management function as the master instance. Therefore, it is necessary to notify the slave instance to transfer the master-slave status through a heartbeat message. After the notification is completed, wait for the status switch notification from the slave instance. (The embodiment of the present invention does not consider the situation where the slave instance notification is not received after waiting for a period of time)

[0072] When receiving a state switching notification from a slave instance, parse the notification content.

[0073] Step 1. If the master-slave transfer is accepted, the role switch will start, the master instance will be set to "slave waiting", and the slave instance will be notified to switch roles. Continue to wait for the role switch completion notification from the slave instance. When receiving the notification, the "slave waiting" must be set to "slave instance", and the entire transfer process on the master instance ends here.

[0074] Step 2. If you do not agree to the master-slave transfer, the master instance must continue to maintain the master role and the transfer process ends.

[0075] From the perspective of the instance side, when receiving the master-slave transfer notification from the master instance side, it determines whether it has the conditions to switch to the master instance based on its own internal situation. If it has, it notifies the master instance side that it can switch to the master instance. If it does not have, it notifies the master instance side that it cannot switch to the master instance. After the notification is completed, continue to wait for the message from the master instance side. When receiving the role switching notification from the master instance side, it is necessary to set the slave instance to "master instance". After the setting is completed, the latest instance role should be notified to the original master instance side in time to end the transfer process. The transfer process from the instance side ends here.

[0076] In view of the requirements of high safety and high reliability of the integrated modular avionics system, the embodiments of the present invention put forward hot standby requirements for the health management functions of the basic equipment in the cabinet, including the power management module, fans / valves, etc. Taking into account the requirements for the robustness of these basic equipment, when the main instance of the device is operating normally, the slave instance starts normally but does not provide external service functions. In the event of a failure or abnormality in the main instance, the slave instance immediately switches to the main instance and provides normal service functions to the outside. Based on the design of this mechanism, real-time communication is required between the master and slave instances to monitor the current internal status of the equipment. The master instance monitors the status of the slave instance in real time to ensure that the backup module is always ready to stand by and provide external services in an instant under abnormal circumstances.

[0077] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A comprehensive modular avionics system basic equipment safety management method, characterized in that: include: Instance 1 and instance 2 for basic equipment health management are powered on and start arbitration respectively, and a master instance and a slave instance are determined by the start arbitration, wherein instance 1 and instance 2 determine each other's current state by obtaining heartbeat messages published by each other; The master instance and the slave instance perform post-startup arbitration in real time to determine whether to perform master-slave status switching; The slave instance reports its current status to the master instance by publishing heartbeat information, and the master instance reports the functional status of all basic devices in the entire cabinet to the health management platform; The process of starting arbitration includes: if the instance 1 determines that the current state of the instance 2 is inactive or activated as a slave instance through the heartbeat message published by the instance 2, the instance 1 sets its own state to the master instance; if the instance 2 determines that the current state of the instance 1 is inactive or activated as a slave instance through the heartbeat message published by the instance 1, the instance 2 sets its own state to the master instance; The post-startup arbitration process includes: when the master instance receives a state switching notification from the slave instance, the master instance judges its own current functional state, and determines whether to agree to the state switching according to the judgment result; if agreed, the master instance sets its own state to slave waiting, and notifies the slave instance to switch the state, and when the master instance receives a switching completion notification sent by the slave instance, it sets its own state to the slave instance; when the slave instance receives a state switching notification from the master instance, the slave instance judges its own current functional state to determine whether it has the conditions for switching to the master instance, and if so, switches its own state to the master instance.

2. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The process of starting arbitration also includes: if both the instance 1 and the instance 2 are in an activated state, and the instance 2 is activated as a master instance, the instance 1 sets its own state to a slave instance.

3. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The process of starting arbitration also includes: if both the instance 1 and the instance 2 are in an activated state, and the instance 1 is activated as a master instance, the instance 2 sets its own state to a slave instance.

4. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The post-startup arbitration process further includes: if both the instance 1 and the instance 2 are slave instances, the instance 1 sets its own state to be the master instance.

5. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The post-startup arbitration process further includes: if both the instance 1 and the instance 2 are master instances, the instance 2 sets its own status to a slave instance.

6. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The post-startup arbitration process further includes: when the main power supply of the master instance is lost, the master instance sends the state switching notification to the slave instance, wherein the state switching notification includes a time interval for the state switching.

7. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The post-startup arbitration process also includes: the slave instance makes a judgment based on the heartbeat message published by the master instance, and if the current functional state of the slave instance itself is better than the current functional state of the master instance, the slave instance sends the state switching notification to the master instance.

8. The method for safety management of basic equipment of an integrated modular avionics system according to claim 1, characterized in that: The post-startup arbitration process also includes: when the slave instance receives a status switching notification from the master instance, the slave instance judges its current functional status to determine whether it has the conditions to switch to the master instance; if so, the slave instance notifies the master instance through a heartbeat message that it can currently switch to the master instance; upon receiving a switching consent message sent by the master instance, the slave instance switches its status to the master instance and sends a switching completion notification to the master instance.

9. The method for safety management of basic equipment of an integrated modular avionics system according to claim 8, characterized in that: The post-startup arbitration process also includes: when the master instance receives a message from the slave instance that it can currently switch to the master instance, the master instance sets its own state to slave waiting, and when receiving the switching completion notification sent by the slave instance, the master instance switches its own state from slave waiting to slave instance.

Images