A comprehensive modular avionics system basic equipment safety management method

Abstract

The present invention provides a method for safety management of basic equipment of an integrated modular avionics system, which relates to the field of integrated avionics technology, including: Instance 1 and Instance 2 for basic equipment health management are powered on separately and start arbitration, and the master instance and the slave instance are determined by the start arbitration, wherein the instance 1 and the instance 2 determine each other's current status by obtaining the heartbeat message published by the other party; the master instance and the slave instance perform post-start arbitration in real time to determine whether to switch the master-slave status; 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 equipment in the entire cabinet to the health management platform. The present invention ensures that a robust and guaranteed basic equipment health management service is provided for the platform-level health management function by switching between master and slave instances in abnormal scenarios.

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, and the security and reliability of the avionics software are crucial to the safety of the entire aircraft. With this in mind, the health management functions for the cabinet's infrastructure, including power management modules, fans, and valves, must consider how to ensure stable and robust health management services in the event of a partial functional loss. This is crucial to the safety of the entire avionics system. Therefore, addressing the issue of hot backup for the health management of infrastructure within the integrated modular avionics system is crucial to ensuring robust and reliable infrastructure health management services for platform-level health management functions. 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 present application provides the following technical solution: a comprehensive modular avionics system infrastructure equipment security management method, including:

[0005] Instances 1 and 2 for basic device health management are powered on and start arbitration, respectively. A master instance and a slave instance are determined through the arbitration. Instances 1 and 2 determine each other's current status 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 a master-slave state switch;

[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 initiating 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 based on the judgment result; if agreed, the master instance sets its own state to slave waiting and notifies the slave instance to switch the state; when the master instance receives a switching completion notification sent by the slave instance, the master instance sets its own state to slave instance; when the slave instance receives a state switching notification from the master instance, the slave instance judges its own current functional state and determines whether it has the conditions for switching to the master instance; if so, the slave instance switches its state to the master instance.

[0010] According to an embodiment of the present application, the process of initiating arbitration further 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 further 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 instance 1 and instance 2 are slave instances, instance 1 sets its own status to a master instance.

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

[0014] According to one 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; if the current functional status of the slave instance itself is better than the current functional status of the master instance, the slave instance sends the status 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, it notifies the master instance through a heartbeat message that it can currently switch to the master instance. Upon receiving a consent switching message sent by the master instance, the slave instance switches its own 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 status to slave waiting, and when the master instance receives the switching completion notification sent by the slave instance, the master instance switches its own status 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 master and slave instances in the embodiments of the present invention ensures that the IMA platform has robust basic equipment health management capabilities in abnormal scenarios. The master-slave instance switching process is transparent and invisible to external users of the platform, and is imperceptible to external users. It is consistent with the situation when both instances are completely normal, and can provide highly reliable services.

[0020] 2. In the embodiment of the present invention, the master-slave arbitration during 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 provides basic equipment health management functions.

[0021] 3. In the embodiment of the present invention, the master-slave arbitration process based on specific conditions after startup is completed 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 following briefly introduces the drawings required for use in the embodiments. 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 any creative work.

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

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

[0025] Figure 3 This 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 according to an embodiment of the present invention;

[0027] Figure 5 This 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 embodiments 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 embodiments, 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 features in the following embodiments and embodiments can be combined with each other. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative work are within the scope of protection of this application.

[0030] In an embodiment of the present invention, the cabinet-level basic device health management function is responsible for providing health management for devices not directly connected to the avionics data network, including power management modules (PSMs), fans / valves, and other devices. This function is implemented as an application within the integrated modular avionics system and maintenance components. The basic device health management function runs as two redundant instances, residing on two separate general-purpose computing modules (GCMs) in each cabinet and providing access to the cabinet's internal communication bus. Each health management instance can publish cabinet periodic monitoring report information, but the platform-level health management function only expects one instance to be in use at any given time. For this reason, only the master instance publishes cabinet periodic monitoring reports to the platform-level health management function, and communication can occur via the cabinet's internal communication bus. Upon becoming the master instance, it begins sending cabinet periodic monitoring reports. Slave instances report their status to the master instance via heartbeat messages. The master instance is responsible for reporting the functional status of all basic devices within the cabinet, including the status of slave instances.

[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] Two health management instances synchronize by publishing heartbeat messages and monitoring these messages from the other instance. The redundancy information in the heartbeat messages is used to determine the master instance of the infrastructure health management.

[0033] Each instance has four states: Power Up, Slave, Master, and Slave Waiting (Master waiting to switch to Slave). These four states should be reflected in the heartbeat message. This 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 a single cabinet 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 comprehensive modular avionics system infrastructure equipment security management method, including:

[0036] Instances 1 and 2 for basic device health management are powered on and start arbitration, respectively. A master instance and a slave instance are determined through the arbitration. Instances 1 and 2 determine each other's current status 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 a master-slave state switch;

[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 initiating 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 based on the judgment result; if agreed, the master instance sets its own state to slave waiting and notifies the slave instance to switch the state; when the master instance receives a switching completion notification sent by the slave instance, the master instance sets its own state to slave instance; when the slave instance receives a state switching notification from the master instance, the slave instance judges its own current functional state and determines whether it has the conditions for switching to the master instance; if so, the slave instance switches its state to the master instance.

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

[0042] In some embodiments, 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, 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 start 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 is 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 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 master instance, instance 1 will continue to be "Secondary" and instance 2 will continue 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 judging 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 and no switching operation is performed.

[0048] Step 2: If a dual-master instance exists, instance 1 remains the master instance and instance 2 switches to the slave instance. Alternatively, if a dual-slave instance exists, instance 1 switches to the master instance and instance 2 remains the slave instance. In all other cases, master-slave transition (as described above) is required.

[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 approved, the role switch begins. The master instance is set to "Slave Waiting" and the slave instance is notified to initiate the role switch. Wait for the slave instance to receive a notification that the role switch is complete. Upon receiving the notification, the master instance's "Slave Waiting" status is changed to "Slave Instance." This completes the master instance's role switch process.

[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. 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 conditions. 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 a timely manner to end the transfer process. The transfer process on the slave instance side 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 with reference to 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, slave instance, and master instance) is as follows:

[0057] Step 1. At the start 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 in the slave state, instance 1 will set its own role to "Primary". Similarly, if instance 2 finds that instance 1 is not activated or is activated in the slave state, instance 2 will set its own role to "Primary". When both instances are in the active state, if instance 1 is the slave instance and instance 2 is the master instance, instance 1 will continue to be "Secondary" and instance 2 will continue to be "Primary". The other three cases are all processed as instance 1 being the master and instance 2 being the slave. The processing process is as follows Figure 4 shown.

[0059] After the startup is complete, 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 as follows:

[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 primary instance, and instance 2 is also the primary instance.

[0065] After at least one cabinet infrastructure health management instance is started, the possible states of instance 1 and instance 2 are shown in Table 1, 1 to 4. During program operation, the possible states of instance 1 and instance 2 are shown in Table 1, 5 to 12.

[0066] Table 1. Status of basic device 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] If we analyze both states 1 and 2 together, we see that only one module has been successfully activated. If another module is subsequently detected, the module that started first will continue to be the master instance, and the module that started later will change from "inactive" to "slave." At this point, state 1 becomes state 3, and state 2 becomes state 4.

[0069] Looking at states 3 and 4, considering the internal conditions of the master instance after startup, there is a possibility of a power loss, which could trigger a master-slave transition. Master-slave transition occurs after startup, based on specific arbitration conditions, where two basic device instances jointly elect a master instance based on their own conditions and the other instance's internal conditions. This also refers to the dynamic adjustment of master and slave roles after startup. After the master-slave transition, the module roles enter a relatively stable state.

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

[0071] From the master instance's perspective, if the current master instance loses both main power supplies, it will lose power within 11 seconds. At this point, it is no longer suitable to serve as the master instance and report the cabinet status to the platform-level health management function. Therefore, it is necessary to notify the slave instance via a heartbeat message to transfer the master-slave status. After the notification is completed, wait for the state transition notification from the slave instance. (This embodiment of the present invention does not consider the situation where the slave instance fails to receive a notification 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 approved, the role switch begins. The master instance is set to "Slave Waiting" and the slave instance is notified to initiate the role switch. Wait for the slave instance to receive a notification that the role switch is complete. Upon receiving the notification, the master instance's "Slave Waiting" status is changed to "Slave Instance." This completes the master instance's role switch process.

[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 instance side, upon receiving a master-slave transition notification from the master instance, it determines whether it meets the conditions for transitioning to master status based on its internal conditions. If so, it notifies the master instance that it can transition to master. If not, it notifies the master instance that it cannot. After receiving this notification, it continues to wait for further information from the master instance. Upon receiving a role transition notification from the master instance, it sets the slave instance to master. Once this is complete, the new instance role should be promptly notified to the original master instance, completing the transition process. This concludes the slave instance transition process.

[0076] In response to the high safety and high reliability requirements of the integrated modular avionics system, the embodiment of the present invention proposes a hot standby requirement for the basic equipment in the cabinet, including the power management module, fans / valves and other health management functions. Taking into account the robustness requirements of these basic equipment, when the main instance of the device is operating normally, the slave instance starts normally but does not provide external services. 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 world. 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 and on standby, and can provide external services immediately in abnormal situations.

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

Claims

1. A comprehensive modular avionics system infrastructure safety management method, characterized by: include: Instances 1 and 2 for basic device health management are powered on and start arbitration, respectively. A master instance and a slave instance are determined through the arbitration. Instances 1 and 2 determine each other's current status 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 a master-slave state switch; 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 initiating 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 based on the judgment result; if agreed, the master instance sets its own state to slave waiting and notifies the slave instance to switch the state; when the master instance receives a switching completion notification sent by the slave instance, the master instance sets its own state to slave instance; when the slave instance receives a state switching notification from the master instance, the slave instance judges its own current functional state and determines whether it has the conditions for switching to the master instance; if so, the slave instance switches its state to the master instance.

2. The integrated modular avionics system infrastructure safety management method according to claim 1, characterized in that: The process of starting arbitration further 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 integrated modular avionics system infrastructure safety management method according to claim 1, characterized in that: The process of starting arbitration further 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 integrated modular avionics system infrastructure safety management method 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 status to the master instance.

5. The integrated modular avionics system infrastructure safety management method 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 integrated modular avionics system infrastructure safety management method 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 state switching.

7. The integrated modular avionics system basic equipment safety management method 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; 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 integrated modular avionics system infrastructure safety management method 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 own 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 own status to the master instance and sends a switching completion notification to the master instance.

9. The integrated modular avionics system basic equipment safety management method 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 indicating that it can currently switch to the master instance, the master instance sets its own state to slave waiting, and when the master instance receives the switching completion notification sent by the slave instance, the master instance switches its own state from slave waiting to slave instance.

Images