New Model-Based Analysis Method with Multiple Constraints for Integrated Modular Avionics Dynamic Reconﬁguration Process

: With the development of integrated modular avionics (IMA), the dynamic reconﬁguration of IMA not only provides great advantages in resource utilization and aircraft conﬁguration, but also acts as a valid means for resource failure management. It is vital to ensure the correction of the IMA dynamic reconﬁguration process. The analysis of the dynamic reconﬁguration process is a signiﬁcant task. The Architecture Analysis & Design Language (AADL) is widely used in complicated real-time embedded systems. The language can describe the system conﬁguration and the execution behaviors, such as conﬁguration changes. Petri net is a widely used tool to conduct simulation analysis in many aspects. In this study, a model-based analyzing method with multiple constraints for the IMA dynamic reconﬁguration process was proposed. First, several design constraints on the process were investigated. Second, the dynamic reconﬁguration process was modeled based on the AADL. Then, a set of rules for the transition of the model from AADL to Petri net was generated, and the multi-constraints proposed were incorporated into Petri net for analysis. Finally, a simulation multi-constraint analysis with Petri net for the process of IMA dynamic reconﬁguration was conducted. Finally, a case study was employed to demonstrate this method. This method is advantageous to the validity of IMA dynamic reconﬁguration at the beginning of the system design.


Introduction
An avionic system is developed from a discrete one, to the federal one and to the integrated modular avionics (IMA). The system has more open and more complex architectures. The IMA system executes functions based on common functional modules (CFMs). The CFMs help to reduce the weight and size of a plane. In an IMA system, various software functions run on CFMs. The software system is highly integrated because of its complex structure.
Based on the description of IMA in ARINC 653 and by the Allied Standards Avionics Architecture Council (ASAAC) [1,2], the software architecture has a three-layer structure. The application software is initially stored in a data storage device and not the CFMs. The software and hardware is not binding. The software can be used on different hardware with different configurations. For safety purposes, the planes usually restart the applications by redundant backups once some failure occurs. In this paper, dynamic reconfiguration refers to configuration changes conducted when failure occurs during flying. Dynamic reconfiguration can help in creating new backup areas to restart an application, which makes the plane more flexible and utilizes the hardware resources more effectively.
in system safety, reliability and risk assessment in many fields. Li et al. [41] proposed a PN-based reliability modelling method when system reliability was evaluated, considering the dependence of the failure mechanism. Wieland et al. [42] proposed a PN based model to calculate the reliability data of polymer-electrolyte-membrane fuel cell stacks. The reliability data include the average lifetime of a single stack or the reliability of the stacks of a whole fuel cell vehicle fleet within a given time. Sunanda et al. [43] proposed a Petri net-based fault modelling approach, and the approach was validated by applying it to a prototype rail-road crossing junction system. Li, W. [44] proposed a novel layered fuzzy Petri nets modelling and reasoning method for a process equipment failure risk assessment, in order to describe the coupling relationship clearly and make the computational process flexible. Gonçalves, P. [45] presented a safety assessment process modelling of a UAV by Petri Nets, for the analysis of fault conditions that lead to the most feared events. Liu, R. [46] translated the AADL model intro GSPN for analyzing and assessing the reliability of the IMA system platform. Li, Z. [47] proposed a hazard analysis via an improved timed CPN with time-space coupling safety constraint for IMA.
However, in the aspect of modelling embedded systems, Petri nets suffer from combinatorial and complexity problems and, hence, are difficult to be used in the modelling of complex systems with a significant number of states [48]. Therefore, in this study, we applied AADL to model the dynamic reconfiguration process of IMA, and to simulate and analyze the model by transformation to Colored Petri Nets.
The rest of this paper is organized as follows: Section 2 provides a brief introduction about IMA dynamic reconfiguration, AADL, classical Petri net, CPN, etc. A set of constraints for dynamic reconfiguration are proposed in Section 3. Then, Section 4 presents the analyzing method that contains three steps. First, the dynamic reconfiguration process is modeled based on AADL, and the properties related to the constraints are added to this model. Second, the AADL model is transformed into a CPN in some specific rules. Third, the dynamic reconfiguration process is simulated based on a Petri net. A case study is proposed to describe this method in detail in Section 5. A conclusion to our study and future research work is provided in Section 6.

IMA Software Architecture
The IMA system is a complex system that has more open architectures, more widespread integration, more integrated functions, and high coupling between modules. Many challenges also appear when reconfiguration occurs. Dynamic reconfiguration in this study pertains to software. Then, the architecture of IMA software is introduced in this paper. The IMA system includes the IMA core system and noncore equipment, according to the ASAAC standard. The IMA core system contains several avionic racks. These racks contain CFMs and communication nets between them. Moreover, the racks have functional applications based on hardware, the operational system, and system management software.
A CFM provides computing power, net support, and power conversion for the IMA core system. The software system is divided into three layers-the module support layer (MSL), operating system layer (OSL), and application layer (AL). The MSL provides an interface for the above layer to access the resources and separates the operating system and the hardware platform. The OSL includes a real-time operation system and system management. Software application and application management are conducted on the AL. The general system management (GSM) in the OSL, which performs system management, configures and manages the system by the accessing the system blueprint. The GSM includes health management, fault management, configuration management, and safety management. Application management is part of system management, and is operated based on the application. The software architecture is displayed in Figure 1.

IMA Reconfiguration Mechanism
IMA reconfigurations include both static and dynamic reconfigurations [50,51]. Some mechanisms are common for both static and dynamic reconfigurations. In the IMA core system, all the software applications are stored in the mass memory. When the system is initialized, the applications load on the target module [52]. This operation reduces the need for maintenance, and ensures that the module can be replaced. When some failures occur, a health manager detects the failure and informs a fault manager to handle it. The fault manager can handle a series of failures in order under all types of mechanism. On the one hand, a fault manager can detect, locate, and relate the failures, and then report the analysis results to the upper layer. On the other hand, the system requests the configuration manager to begin reconfiguration to evade the failure. In summary, the fault manager synthesizes many fault management technologies. Then, the configuration manager begins his work after receiving the message from the fault manager [53,54].
There are many principles in ASAAC for reconfiguration. The IMA system should be reconfigured between stable states. The reconfiguration needs to stop the spread of the fault as soon as possible. The system design must consider the entire situation when some reconfiguration exists. A reconfiguration implies the relocation of an application, due to some requirements or when a failure occurs. The reconfiguration actions follow the order from the blueprint. Reis et al. [55] pointed out that reconfiguration is helpful when there are dynamic nonfunctional requirements, hardware defects, or application requirements for a system.
However, there are differences between the static and dynamic reconfigurations. Usually, the static reconfiguration system includes redundant modules. For example, CRACK2 is a redundant crack for CRACK1. Then, CFM3/REP2 is a backup for CFM3/REP1. When CFM3/REP1 fails, the applications run on CFM3 and can be transferred to REP2 from REP1, to make the system free from failure. The static reconfiguration of a system is presented in Figure 2.

IMA Reconfiguration Mechanism
IMA reconfigurations include both static and dynamic reconfigurations. Some mechanisms are common for both static and dynamic reconfigurations. In the IMA core system, all the software applications are stored in the mass memory. When the system is initialized, the applications load on the target module [49]. This operation reduces the need for maintenance, and ensures that the module can be replaced. When some failures occur, a health manager detects the failure and informs a fault manager to handle it. The fault manager can handle a series of failures in order under all types of mechanism. On the one hand, a fault manager can detect, locate, and relate the failures, and then report the analysis results to the upper layer. On the other hand, the system requests the configuration manager to begin reconfiguration to evade the failure. In summary, the fault manager synthesizes many fault management technologies. Then, the configuration manager begins his work after receiving the message from the fault manager [50,51].
There are many principles in ASAAC for reconfiguration. The IMA system should be reconfigured between stable states. The reconfiguration needs to stop the spread of the fault as soon as possible. The system design must consider the entire situation when some reconfiguration exists. A reconfiguration implies the relocation of an application, due to some requirements or when a failure occurs. The reconfiguration actions follow the order from the blueprint. Reis et al. [52] pointed out that reconfiguration is helpful when there are dynamic nonfunctional requirements, hardware defects, or application requirements for a system.
However, there are differences between the static and dynamic reconfigurations. Usually, the static reconfiguration system includes redundant modules. For example, CRACK2 is a redundant crack for CRACK1. Then, CFM3/REP2 is a backup for CFM3/REP1. When CFM3/REP1 fails, the applications run on CFM3 and can be transferred to REP2 from REP1, to make the system free from failure. The static reconfiguration of a system is presented in Figure 2.

Related Work for Dynamic Reconfiguration
Based on ARINC 653 [53], errors (fault) in IMA and response mechanisms are classified as shown in Table 1.

Related Work for Dynamic Reconfiguration
Based on ARINC 653 [56], errors (fault) in IMA and response mechanisms are classified as shown in Table 1.   Therefore, when errors occur in IMA systems, the response mechanisms e.g., fault tolerance techniques, etc. will start to respond first. When the response mechanisms are unable to solve the error (fault), the error will trigger a dynamic reconfiguration. In this study, we aim to discuss and analyze the situations after the reconfiguration process starts, therefore, we assume it is not possible for response mechanisms to solve the fault, and that it has triggered the reconfiguration.
IMA dynamic reconfiguration occurs while the system is operating. In this study, the reconfiguration just pertains to the software, because hardware failure is irreversible [54]. IMA dynamic reconfiguration can change its tasks based on the requirement and recover rapidly from a failure [55]. This makes the system more flexible, and reduces hardware redundancy and the cost of unscheduled maintenance. Moreover, when a human is involved, the complexity of dynamic reconfiguration increases. Then, determining how to restrain the process to ensure its safety becomes a problem. Many researchers have explored the improvement of dynamic reconfiguration under all types of aspects.
Topping, C. [56] introduced a dynamically reconfigurable processing module (DRPM) for dynamic reconfiguration. The DRPM is made up of reprogrammable field programmable gate arrays (FPGAs), which is the basic hardware required for convenient reconfiguration. Suo [57] proposed that traditional analysis methods mostly focus on component failure. STPA is used to perform hazard analysis that focuses on human factors underlying the dynamic process. Temporal planners are proposed in [58], to plan the process of dynamic reconfiguration under stringent time and resource constraints. The preparation of a reconfiguration plan was difficult for most researchers in the past, due to the lack of automated and intelligent tools. They automated the dynamic reconfiguration by using artificial intelligence (AI) temporal planners to reduce its complexity. The AI planners conduct optimized task planning, which makes it difficult for humans to find out when a system is reconfigured. Montano [59] defined the elements in a dynamic reconfiguration in his thesis. A safety-critical manned systems (SCMS) dynamic reconfiguration is driven by an event to change functions or resources to meet the requirements of the operator. The thesis discusses automation and human involvement during the dynamic reconfiguration of a safety-critical system.
For the modeling of IMA dynamic reconfiguration, Zhang [60] proposed a reliability method based on AADL for IMA reconfiguration. The system was then translated to a Petri net for reliability analysis. The reliability calculation is for components of the system architecture. Suo introduced a method to address the real-time problems in the reconfiguration in another study [61]. The IMA system is also modeled using AADL. Then, the system is translated to TPN for verification.
Above all, the analysis for the dynamic reconfiguration process has not drawn much attention. This study proposed a method for analyzing the process, based on models to enhance the correctness, safety, and reliability of dynamic reconfiguration.

AADL
AADL is an effective modeling tool for analyzing real-time embedded systems and complex systems. In this study, AADL was employed to model the process of dynamic reconfiguration of IMA.

Components
Components are the core elements of a system. The components are divided into three sets-software, hardware, and composite. The configuration state of a system can be described by AADL. Moreover, the system structure and devices can be described. The software architecture of the IMA system is partitioned. Then, the logic configuration structure needs ARINC 653 annex in AADL. The ARINC 653 elements formed the system architecture and correspond to the AADL components [62].

Modes
A stable configuration state of the system during dynamic reconfiguration is represented by a mode. Modes can represent various states of a system or component, connections, and property value associations [63]. Mode transitions determine when the system is reconfigured dynamically to a new configuration. The textual and graphical representations of mode transition specifications for a simple example are shown in Figure 3.

Behavior Annex
Every state of a system and the detailed transitions are expressed by the behavior annex in AADL. The behavior annex defines the behavior specifications of the AADL components in a more refined than the core of the language. The behaviors described in this annex are based on state variables whose evolution is specified by transitions that can be characterized by conditions and actions [67].

Petri Net
AADL is widely used for modeling the embedded system. The AADL cannot perform the simulation analysis of the dynamic process visually. A Petri net is a compatible tool to conduct a simulation analysis.
A Petri net is a graphical and mathematical modeling tool for describing systems that are concurrent and asynchronous. Petri nets can not only simulate the dynamic activities or information transmission of a network, but also use mathematical models to govern the behavior of systems [68]. A Petri Net is described as a three-tuple = ( , , ) [69], where is a finite set of places; is a finite set of transitions; is a set of directed arcs. A classical Petri net comprises place, transitions, and arcs between places. The state of a system is usually described by a place. Transitions represent the changing process of systems. Arcs from a transition to a place, or from out of a place to a transition, have their weights. Tokens are present in each place to show the state of the place. Tokens are also used to represent data or resources. However, there are some shortcomings of a classical Petri net. A classical Petri net has no conception of time. Moreover, the description method of classical Petri nets is too single. Thus, there are many extensions and supplements for Petri nets. Some highlevel Petri nets, such as CPNs and timed Petri nets, have been proposed. CPNs are a high-level Petri nets used for designing, specification analysis, validation, and verification [70,71]. A CPN is a tuple = (Σ, , , , , , , , ) [72], where: Σ is a finite set of non-empty types, also called colour sets; is a finite set of places; is a finite set of transitions; is a finite set of arcs; is a node function; is a color function; is a guard function; is an arc expression function; is an initialization function. CPNs can describe the states of complex systems and state changes, due to triggering events. The feature of a CPN is that it provides a definition of color sets. A color set attached to a place has tokens in it. Each token should have a color. The guard of a transition needs to be satisfied before the transition is conducted. A CPN combines Petri nets and a programming language standard ML [73].

Behavior Annex
Every state of a system and the detailed transitions are expressed by the behavior annex in AADL. The behavior annex defines the behavior specifications of the AADL components in a more refined than the core of the language. The behaviors described in this annex are based on state variables whose evolution is specified by transitions that can be characterized by conditions and actions [62].

Petri Net
AADL is widely used for modeling the embedded system. The AADL cannot perform the simulation analysis of the dynamic process visually. A Petri net is a compatible tool to conduct a simulation analysis.
A Petri net is a graphical and mathematical modeling tool for describing systems that are concurrent and asynchronous. Petri nets can not only simulate the dynamic activities or information transmission of a network, but also use mathematical models to govern the behavior of systems [64]. A Petri Net is described as a three-tuple PN = (P, T, F) [65], where P is a finite set of places; T is a finite set of transitions; F is a set of directed arcs. A classical Petri net comprises place, transitions, and arcs between places. The state of a system is usually described by a place. Transitions represent the changing process of systems. Arcs from a transition to a place, or from out of a place to a transition, have their weights. Tokens are present in each place to show the state of the place. Tokens are also used to represent data or resources. However, there are some shortcomings of a classical Petri net. A classical Petri net has no conception of time. Moreover, the description method of classical Petri nets is too single. Thus, there are many extensions and supplements for Petri nets. Some high-level Petri nets, such as CPNs and timed Petri nets, have been proposed.
CPNs are a high-level Petri nets used for designing, specification analysis, validation, and verification [66,67]. A CPN is a tuple CPN = (Σ, P, T, A, N, C, G, E, I) [68], where: Σ is a finite set of non-empty types, also called colour sets; P is a finite set of places; T is a finite set of transitions; A is a finite set of arcs; N is a node function; C is a color function; G is a guard function; E is an arc expression function; I is an initialization function. CPNs can describe the states of complex systems and state changes, due to triggering events. The feature of a CPN is that it provides a definition of color sets. A color set attached to a place has tokens in it. Each token should have a color. The guard of a transition needs to be satisfied before the transition is conducted. A CPN combines Petri nets and a programming language standard ML [69].
Recently, there have been some studies on model-based analysis approaches for dynamic reconfiguration. A reliability method based on AADL for IMA reconfiguration was proposed by Zhang [60]. The reliability calculation for components of the system is conducted after a model transition from AADL to Petri net. Suo [64] introduced a method modeled by AADL, and translated to TPN to address the real-time problems in the reconfiguration. Van der Aalst [70] pointed out that Petri nets not only are used as a design language for the specification of complex workflows, but also provide powerful analysis techniques to verify the correctness of workflow procedures. To the best of our knowledge, no analysis approach has focused on the dynamic reconfiguration process. In this study, a model-based analysis method for the process of dynamic reconfiguration was proposed to perform a hazard analysis.

Multi-Constraints for the Dynamic Reconfiguration Process
Here, a set of constraints was proposed for the IMA dynamic reconfiguration process. The constraints involve many aspects such as system states, real-time possibility, and resource ability. All the mentioned constraints were integrated into the analysis method, for checking the correctness of the design of IMA dynamic reconfiguration.

System State Constraints for Dynamic Reconfiguration
Before dynamic reconfiguration is triggered, some pre-checks of the modules in the system except the failure module should be conducted. If fault propagation has occurred, the initial setup strategy of dynamic reconfiguration should be abandoned. A new dynamic reconfiguration should be considered. A Boolean value S is set, to represent the initial state of the system. If the other modules of the system also fail after spreading, then S = 0. Thus, reconfiguration is terminated. If there is no spreading of the failure, the system can start reconfiguration, S = 1.

Real-Time Constraints for System State Transition
A brief introduction to the process of dynamic reconfiguration is conducted in Section 2. During the process, a system changes from one state to another, due to triggering events and actions. It is an important problem where the limits of time must be ensured. If the time between two states is very long, it affects the next state and causes some reconfiguration hazards. Analysis properties should be added in a model.
A time property is bonded to a transition from one state to the next state. To guarantee the time constraints, an algebraic equation that compares the sum of the time consumed by all the substates during the dynamic reconfiguration process with the limitation value was proposed. Figure 4 presents that there are five states in a process. There is a trigger for transition between state 0 and state 1. The time for the transition is T 1 . There is an action costing time T 2 between state 1 and state 2. This is similar for the other states. Each action or transition between two states in the process is labeled with the time consumed T i . The limit time is t. Then, the total consuming time T s is the sum of T i . All the time satisfies Equation (1).

Memory Constraints for System State
Similar to the time constraint, all the operations need their memory space, as shown in Figure 5. Obviously, the memory size allocated by each state during dynamic reconfiguration can be changed. The constraints of the memory size should be guaranteed, no matter how the demanding memory of substates changes. The behavior of dynamic reconfiguration should obey Equation (2): By using this equation, a comparison between various time values can give us the result, whether the system can achieve the real-time constraint goals.

Memory Constraints for System State
Similar to the time constraint, all the operations need their memory space, as shown in Figure 5. Obviously, the memory size allocated by each state during dynamic reconfiguration can be changed. The constraints of the memory size should be guaranteed, no matter how the demanding memory of substates changes.

Memory Constraints for System State
Similar to the time constraint, all the operations need their memory space, as shown in Figure 5. Obviously, the memory size allocated by each state during dynamic reconfiguration can be changed. The constraints of the memory size should be guaranteed, no matter how the demanding memory of substates changes. Each state including the actions occupies memory . The maximum limitation of the memory size is . Then, Inequation (3) should be obeyed.

Ability Constraint for Sharing Data Resources
Under different modes of the system, the components of a system interact with the data components by reading and writing. The sharing of resources such as data should be marked with a serial number related to the time after operation in different states. If there is no mark on the data components after changing the data in state 1, then the system cannot decide whether the data is the result the system wants in state 2 after checking at the beginning of state 2. The absence of an operation in state 1 may stop the system from changing to the next state. This can be presented as Figure 6.

Ability Constraint for Sharing Data Resources
Under different modes of the system, the components of a system interact with the data components by reading and writing. The sharing of resources such as data should be marked with a serial number related to the time after operation in different states. If there is no mark on the data components after changing the data in state 1, then the system cannot decide whether the data is the result the system wants in state 2 after checking at the beginning of state 2. The absence of an operation in state 1 may stop the system from changing to the next state. This can be presented as Figure 6.

Memory Constraints for System State
Similar to the time constraint, all the operations need their memory space, as shown in Figure 5. Obviously, the memory size allocated by each state during dynamic reconfiguration can be changed. The constraints of the memory size should be guaranteed, no matter how the demanding memory of substates changes. Each state including the actions occupies memory . The maximum limitation of the memory size is . Then, Inequation (3) should be obeyed.

Ability Constraint for Sharing Data Resources
Under different modes of the system, the components of a system interact with the data components by reading and writing. The sharing of resources such as data should be marked with a serial number related to the time after operation in different states. If there is no mark on the data components after changing the data in state 1, then the system cannot decide whether the data is the result the system wants in state 2 after checking at the beginning of state 2. The absence of an operation in state 1 may stop the system from changing to the next state. This can be presented as Figure 6.  If the mark is correct, then the ability to share the resource (data) is verified appropriately. Assume that the sharing data component is marked with D i at a state i after each state. Then, M(D i ) presents the serial number of D i . At the beginning of the next state, the D i of the data component is checked and the value is C(D i+1 ).
The system needs to satisfy Equation (4).
If Equation (4) is satisfied, it turns out that the data resource is operated correctly. Otherwise, there is something wrong or absent in the former state.

Modeling Approach Based on AADL
The complex process of dynamic reconfiguration is difficult to analyze without modeling. AADL is an effective modeling tool for a real-time embedded system. Dynamic reconfiguration is a process involved in a human operator and automation. The analysis range is quite wide. However, in this study, the events and conditions that change the process are simplified as some triggers. The object is just the process itself. Thus, a detailed decomposition and formalized expression of the simplified process is discussed here.

Dynamic Reconfiguration Process
When one or several failures occur on a module of IMA, a health manager detects the failure and informs a fault manager to handle it. The fault manager can handle a series of failures under all types of mechanism. Then, the fault manager determines the type of failure to take actions to solve it, for example, closing dynamic reconfiguration, or reporting to the upper layer manager.
If it is unable for the fault manager to solve the failure, it will trigger dynamic reconfiguration. When the constraints are unsatisfied in the IMA dynamic reconfiguration process, the process will stop and the system will fail. When the dynamic reconfiguration process starts, the system stops the failure application and backs up the data. The connections are destroyed. Then, the target module of reconfiguration is selected, based on the functional and nonfunctional requirements, such as minimizing the cost of communication. The next step is to create a new partition on another module for the application. Subsequently, application reloading and connection rebuilding are conducted. In this study, the IMA dynamic reconfiguration process is described as serial flow diagrams, based on the assumption that the occurrence probability of each step of reconfiguration process is 100%. We aim to model the simulate the entire dynamic reconfiguration process, and analyze which steps and unsatisfied constraints leading reconfiguration process stop.
A typical process of dynamic reconfiguration is presented in Figure 7. The arrows indicate that messages are being sent during the process. Rectangles represent the important actions that occurred. Compared with the reconfiguration process mentioned in another study that always has redundant modules, dynamic reconfiguration discussed in this study refers to a system without spare modules, especially when reconfiguration in the case of redundancy is not designed, or is used in the system when dynamic reconfiguration begins.
The next part describes the method for modeling this process, followed by an interpretation of the model-based analysis method with these logic constraints.

Modeling of the Dynamic Reconfiguration Process
AADL is introduced above to describe the IMA system. A mode of a system can be associated with the logical configurations. Mode transitions imply that the configuration state changes from one to another [71]. A system or a component has different static structures and properties in different modes. A property can describe task scheduling, real-time characteristics, communication, memory, etc. Then, modes at the system level represent the content of a system configuration. A system has its own modules, partitions, processors, and communication bus in each mode. Thus, the static structure of the system in one mode is built by ARINC 653 annex in AADL. own modules, partitions, processors, and communication bus in each mode. Thus, the static structure of the system in one mode is built by ARINC 653 annex in AADL.  The modeling method proposed in this study is presented in Figure 8. Mode change represents that dynamic reconfiguration occurred. More details and substates between the modes are described using the behavior annex. The trigger condition of the mode transition is declared in the error model annex.
Properties are added to the model, especially to the behavior annex for the following analysis. As the basis of the multi-constraint analysis, elements such as time properties, memory size, and data states are essential elements of the system.  The error model annex [62,72] represents triggering conditions in the reconfiguration caused by failures. An error model type may declare error states, error events, and error propagations. Error model implementations declare error state transitions. Transitions are declared to present the errors that are propagated out of a component based on the current error state of that component. An error property of a guard event may specify that certain patterns of error states and propagations are detected and cause an AADL core event, for example, triggering a mode transition.
The modeling method proposed in this study is presented in Figure 8. Mode change represents that dynamic reconfiguration occurred. More details and substates between the modes are described using the behavior annex. The trigger condition of the mode transition is declared in the error model annex.
Properties are added to the model, especially to the behavior annex for the following analysis. As the basis of the multi-constraint analysis, elements such as time properties, memory size, and data states are essential elements of the system. Processes 2020, 8, x FOR PEER REVIEW 12 of 22

Rules of Model Transformation
The AADL model of IMA dynamic reconfiguration is effective in describing the system structure and complex reconfiguration process. Some analysis can be conducted in tools for AADL, such as Open Source AADL Tool Environment (OSATE) [78]. However, automatic simulation and analysis are not the strong points of AADL, but fit for Petri net. Meanwhile, there are also disadvantages in modelling embedded systems for Petri nets. In this study, modes in AADL model could be presented by places in CPN. Active modes in AADL could be presented by place with specific color token in CPN. Transitions of modes in AADL model could be converted into transition of tokens in CPN. Time properties of the state transitions in AADL model correspond to time stamps of tokens in arcs in CPN. The resources such as memory and data in AADL model that are shared in the system can be represented by tokens in a place in CPN. Finally, the constraints about memory and time in AADL model can be converted to guard functions in a Petri net. Therefore, AADL model can be translated into CPN integrally as shown in Figure 9.

Simulation Analysis with CPN
To clearly perform a demonstration on our CPN model based on the analysis method, a CPN example was employed. Intuitively, there is an example of a simple CPN shown in Figure 10. CPN tools [79] are employed to create a Petri nets. The example of the Petri net has six places. Three of the places represent the states of a system-start, A, and B. A place known as failure reveals a triggering event. A place denoted by D represents the data component. A place named as M represents the memory resource. The arc connects a place and a transition.

Rules of Model Transformation
The AADL model of IMA dynamic reconfiguration is effective in describing the system structure and complex reconfiguration process. Some analysis can be conducted in tools for AADL, such as Open Source AADL Tool Environment (OSATE) [73]. However, automatic simulation and analysis are not the strong points of AADL, but fit for Petri net. Meanwhile, there are also disadvantages in modelling embedded systems for Petri nets. In this study, modes in AADL model could be presented by places in CPN. Active modes in AADL could be presented by place with specific color token in CPN. Transitions of modes in AADL model could be converted into transition of tokens in CPN. Time properties of the state transitions in AADL model correspond to time stamps of tokens in arcs in CPN. The resources such as memory and data in AADL model that are shared in the system can be represented by tokens in a place in CPN. Finally, the constraints about memory and time in AADL model can be converted to guard functions in a Petri net. Therefore, AADL model can be translated into CPN integrally as shown in Figure 9.

Rules of Model Transformation
The AADL model of IMA dynamic reconfiguration is effective in describing the system structure and complex reconfiguration process. Some analysis can be conducted in tools for AADL, such as Open Source AADL Tool Environment (OSATE) [78]. However, automatic simulation and analysis are not the strong points of AADL, but fit for Petri net. Meanwhile, there are also disadvantages in modelling embedded systems for Petri nets. In this study, modes in AADL model could be presented by places in CPN. Active modes in AADL could be presented by place with specific color token in CPN. Transitions of modes in AADL model could be converted into transition of tokens in CPN. Time properties of the state transitions in AADL model correspond to time stamps of tokens in arcs in CPN. The resources such as memory and data in AADL model that are shared in the system can be represented by tokens in a place in CPN. Finally, the constraints about memory and time in AADL model can be converted to guard functions in a Petri net. Therefore, AADL model can be translated into CPN integrally as shown in Figure 9.

Simulation Analysis with CPN
To clearly perform a demonstration on our CPN model based on the analysis method, a CPN example was employed. Intuitively, there is an example of a simple CPN shown in Figure 10. CPN tools [79] are employed to create a Petri nets. The example of the Petri net has six places. Three of the places represent the states of a system-start, A, and B. A place known as failure reveals a triggering event. A place denoted by D represents the data component. A place named as M represents the memory resource. The arc connects a place and a transition.

Simulation Analysis with CPN
To clearly perform a demonstration on our CPN model based on the analysis method, a CPN example was employed. Intuitively, there is an example of a simple CPN shown in Figure 10. CPN tools [74] are employed to create a Petri nets. The example of the Petri net has six places. Three of the places represent the states of a system-start, A, and B. A place known as failure reveals a triggering event. A place denoted by D represents the data component. A place named as M represents the memory resource. The arc connects a place and a transition. In the color set U, p is used to mark whether the place is activated, q means that the place A starts to write to the data component D, Y, or N means whether place A can write to the data. M represents the memory and T1 is used only if the M is in the limitation range. The color set F and F' represent whether the failure event occurred, and whether the initial state of the system is affected.
After simulation with this Petri net, several types of results could be obtained based on the constraint conditions.
1. If all the constraints are fulfilled, the net is simulated to the last place and stops. 2. The system state for dynamic reconfiguration needs checking. The transition T0 can be fired only if the guard function [f = f1 and f' = nof2] is satisfied. This implies that the failure event occurred for triggering dynamic reconfiguration and did not spread to affect the other modules of the system. 3. It should be determined whether the real-time constraints of the system state transition are satisfied or not. Every step in the simulation process is recorded by the time stamp in the transition. When one is step completed, the time consumed is compared with the real-time constraints. The result can tell us if the real-time constraints are met. There is a weakness in this constraint, in that the simulation must be operated manually step by step. 4. Memory constraints of system state do not meet the requirements. A guard function of T1 [y = Y and m ≤ mem_size] is set to define whether the memory size occupied in a state (the color set M) is less than the memory size limitation. In this net, the memory size limitation is 10 M, whereas 15.5 M is required in the process. Then, the net simulation ceases at T1 because it cannot be fired without meeting the guard function. 5. The ability constraint for sharing data resources is fulfilled. If the token from place A to transition W1 does not meet the guard function, the simulation stops. In this net, Y in color set W is sent to W1. The function [y = Y] is accomplished, and the simulation is continued. This means that a mark in demand is added on the data component (place D). The next state can be triggered with this mark. In the color set U, p is used to mark whether the place is activated, q means that the place A starts to write to the data component D, Y, or N means whether place A can write to the data. M represents the memory and T1 is used only if the M is in the limitation range. The color set F and F' represent whether the failure event occurred, and whether the initial state of the system is affected.
After simulation with this Petri net, several types of results could be obtained based on the constraint conditions.

1.
If all the constraints are fulfilled, the net is simulated to the last place and stops. 2.
The system state for dynamic reconfiguration needs checking. The transition T0 can be fired only if the guard function [f = f1 and f' = nof2] is satisfied. This implies that the failure event occurred for triggering dynamic reconfiguration and did not spread to affect the other modules of the system.

3.
It should be determined whether the real-time constraints of the system state transition are satisfied or not. Every step in the simulation process is recorded by the time stamp in the transition. When one is step completed, the time consumed is compared with the real-time constraints.
The result can tell us if the real-time constraints are met. There is a weakness in this constraint, in that the simulation must be operated manually step by step. 4. Memory constraints of system state do not meet the requirements. A guard function of T1 [y = Y and m ≤ mem_size] is set to define whether the memory size occupied in a state (the color set M) is less than the memory size limitation. In this net, the memory size limitation is 10 M, whereas 15.5 M is required in the process. Then, the net simulation ceases at T1 because it cannot be fired without meeting the guard function.

5.
The ability constraint for sharing data resources is fulfilled. If the token from place A to transition W1 does not meet the guard function, the simulation stops. In this net, Y in color set W is sent to W1. The function [y = Y] is accomplished, and the simulation is continued. This means that a mark in demand is added on the data component (place D). The next state can be triggered with this mark.

Case Study
Here, in the case of the IMA system, a series of functional modules including navigation, display, communication, and integrated radio frequency sensors (IRFS) are integrated. The navigation module provides the place of the plane and guides the plane in a definition router. The module for an aircraft cockpit display provides the man-machine interface for a pilot. The communication module is responsible for the communication between an aircraft and a ground unit. IRFS integrates all the RF sensors in the aircraft for sending and receiving signals at all frequency ranges.

Modeling, Transformation, and Simulation
For simplification, an IMA system with four modules is modeled using the AADL in this section. We denote each module with the first letter of its name-navigation module (N), display module (D), communication (C), and IRFS (I). There are several partitions on each module according to their functions. An application runs on a partition. Process refers to the application here. Moreover, it is assumed that there is one partition in module N and module D. Three partitions are set up in module I. The other two partitions are in module C. The application on each partition communicates with GSM to define the operation of connections and applications.
First, the configuration state of a system can be described by AADL. The logic configuration structure needs the ARINC 653 annex in AADL. The ARINC 653 entities fabricated using the system architecture correspond to the AADL components, as introduced in Section 2. The model of the IMA system is presented in a graphical manner based on AADL, as shown in Figure 11.

Case Study
Here, in the case of the IMA system, a series of functional modules including navigation, display, communication, and integrated radio frequency sensors (IRFS) are integrated. The navigation module provides the place of the plane and guides the plane in a definition router. The module for an aircraft cockpit display provides the man-machine interface for a pilot. The communication module is responsible for the communication between an aircraft and a ground unit. IRFS integrates all the RF sensors in the aircraft for sending and receiving signals at all frequency ranges.

Modeling, Transformation, and Simulation
For simplification, an IMA system with four modules is modeled using the AADL in this section. We denote each module with the first letter of its name-navigation module (N), display module (D), communication (C), and IRFS (I). There are several partitions on each module according to their functions. An application runs on a partition. Process refers to the application here. Moreover, it is assumed that there is one partition in module N and module D. Three partitions are set up in module I. The other two partitions are in module C. The application on each partition communicates with GSM to define the operation of connections and applications.
First, the configuration state of a system can be described by AADL. The logic configuration structure needs the ARINC 653 annex in AADL. The ARINC 653 entities fabricated using the system architecture correspond to the AADL components, as introduced in section II. The model of the IMA system is presented in a graphical manner based on AADL, as shown in Figure 11. When the module N fails, the GSM detects the failure and starts the failure management. In this case, the failure causes process 1 to break down and the system reconfiguration. Thus, dynamic reconfiguration is triggered. The process is presented in Figure 12. When the module N fails, the GSM detects the failure and starts the failure management. In this case, the failure causes process 1 to break down and the system reconfiguration. Thus, dynamic reconfiguration is triggered.
(1) After data backup for the process 1, process 1 is shut down and the connections of process 1 in the module N are destroyed. (2) The system selects a proper module to establish a new partition to run process 1. The strategy for selecting the target module is not introduced here. The target module is module D in this case. The process is presented in Figure 12. In this case, a mode is used to represent a configuration state of the system during dynamic reconfiguration. The initial mode is the working state without failure of the system. When a failure occurs, the system changes to mode 1 and module N fails. After the reconfiguration, the system comes to mode 2. Thus, the system works in a new configuration without failure.
The mode transition of the system is revealed in Figure 13. Behavior annex applied between two modes presents the mode transitions with a series of actions, triggers, and conditions, such as the data backup for process 1, and the creation of a new partition on module D, as presented in Figure 12. The properties defined are appended to the behavior annex. A modification is made to define the substates between mode 1 and mode 2. The declaration of the substate set is 'composite state between mode 1 and mode 2 compstate.' Then, each state in the compstate is defined as 'mode 1: initial state, Backup: complete state, Stop_Process: complete state,' and so on. A transition between the state Backup and Stop_Process is presented in the statement 'Backup-[data_backup] -> Stop_Process; {RealtimeProperty: ProcessTime = > 10.0; memory size ≥ 12 MB}.' Time and memory properties in this transition are appended to this transition.
The error model annex is used to represent triggering conditions caused by failures. In this case, one failure event occurs to cause the system to dynamic reconfiguration. The annex describes that the state of the system changes from the initial one without error to an error state. The statement is 'error_free-[error_occurred] -> error_state.' Then the transitions in the error model trigger the system to start reconfiguration. A statement can be 'Error1_trigger ≥ self[detected_state] applies to mode_transition_event.' Based on the rules defined in Section 4, the AADL model of dynamic reconfiguration is converted to CPN. The modes and states of the behavior annex are converted to places in CPN. Mode transitions and behavior annex transitions are converted to transitions in the CPN. Other resources, such as memory and data, are represented by the color set of tokens in places. The triggering condition and constraints are added to the CPN as guard functions for a transition. In this case, a mode is used to represent a configuration state of the system during dynamic reconfiguration. The initial mode is the working state without failure of the system. When a failure occurs, the system changes to mode 1 and module N fails. After the reconfiguration, the system comes to mode 2. Thus, the system works in a new configuration without failure.
The mode transition of the system is revealed in Figure 13. In this case, a mode is used to represent a configuration state of the system during dynamic reconfiguration. The initial mode is the working state without failure of the system. When a failure occurs, the system changes to mode 1 and module N fails. After the reconfiguration, the system comes to mode 2. Thus, the system works in a new configuration without failure.
The mode transition of the system is revealed in Figure 13. Behavior annex applied between two modes presents the mode transitions with a series of actions, triggers, and conditions, such as the data backup for process 1, and the creation of a new partition on module D, as presented in Figure 12. The properties defined are appended to the behavior annex. A modification is made to define the substates between mode 1 and mode 2. The declaration of the substate set is 'composite state between mode 1 and mode 2 compstate.' Then, each state in the compstate is defined as 'mode 1: initial state, Backup: complete state, Stop_Process: complete state,' and so on. A transition between the state Backup and Stop_Process is presented in the statement 'Backup-[data_backup] -> Stop_Process; {RealtimeProperty: ProcessTime = > 10.0; memory size ≥ 12 MB}.' Time and memory properties in this transition are appended to this transition.
The error model annex is used to represent triggering conditions caused by failures. In this case, one failure event occurs to cause the system to dynamic reconfiguration. The annex describes that the state of the system changes from the initial one without error to an error state. The statement is 'error_free-[error_occurred] -> error_state.' Then the transitions in the error model trigger the system to start reconfiguration. A statement can be 'Error1_trigger ≥ self[detected_state] applies to mode_transition_event.' Based on the rules defined in Section 4, the AADL model of dynamic reconfiguration is converted to CPN. The modes and states of the behavior annex are converted to places in CPN. Mode transitions and behavior annex transitions are converted to transitions in the CPN. Other resources, such as memory and data, are represented by the color set of tokens in places. The triggering condition and constraints are added to the CPN as guard functions for a transition. Behavior annex applied between two modes presents the mode transitions with a series of actions, triggers, and conditions, such as the data backup for process 1, and the creation of a new partition on module D, as presented in Figure 12. The properties defined are appended to the behavior annex. A modification is made to define the substates between mode 1 and mode 2. The declaration of the substate set is 'composite state between mode 1 and mode 2 compstate.' Then, each state in the compstate is defined as 'mode 1: initial state, Backup: complete state, Stop_Process: complete state,' and so on. A transition between the state Backup and Stop_Process is presented in the statement 'Backup-[data_backup] -> Stop_Process; {RealtimeProperty: ProcessTime => 10.0; memory size ≥ 12 MB; }.' Time and memory properties in this transition are appended to this transition.
The error model annex is used to represent triggering conditions caused by failures. In this case, one failure event occurs to cause the system to dynamic reconfiguration. The annex describes that the state of the system changes from the initial one without error to an error state. The statement is 'error_free-[error_occurred] -> error_state.' Then the transitions in the error model trigger the system to start reconfiguration. A statement can be 'Error1_trigger ≥ self[detected_state] applies to mode_transition_event.' Based on the rules defined in Section 4, the AADL model of dynamic reconfiguration is converted to CPN. The modes and states of the behavior annex are converted to places in CPN. Mode transitions and behavior annex transitions are converted to transitions in the CPN. Other resources, such as memory and data, are represented by the color set of tokens in places. The triggering condition and constraints are added to the CPN as guard functions for a transition.
In this case, the system creates a new partition on module D that is defined as a substate in the behavior annex. Before the state is activated, the tokens pertaining to memory, and to convey the message that the former state is completed, should be sent to transition. Moreover, the guard function in the transition must be satisfied. For instance, the memory size needs to meet an inequation that the size in need should less than the size exists like Equation (3). The declarations for the CPN model are listed in Figure 14. The CPN model is presented in Figure 15. In this case, the system creates a new partition on module D that is defined as a substate in the behavior annex. Before the state is activated, the tokens pertaining to memory, and to convey the message that the former state is completed, should be sent to transition. Moreover, the guard function in the transition must be satisfied. For instance, the memory size needs to meet an inequation that the size in need should less than the size exists like Equation (3). The declarations for the CPN model are listed in Figure 14. The CPN model is presented in Figure 15.
The 's' in the color set S is a token marking the state transition of the system. Color set F1 represents whether the failure event occurred, and F2 represents whether the initial state of the system is affected. Once the simulation is initiated, the net runs automatically step by step to send the colored tokens when the guard functions are satisfied.

Simulation Results
The results are listed in Table 2 after the simulation was conducted many times under different conditions. The precondition for each result was that the other constraint set in this net meets the requirements for finishing the simulation, except the condition pointed out in Table 2.  In this case, the system creates a new partition on module D that is defined as a substate in the behavior annex. Before the state is activated, the tokens pertaining to memory, and to convey the message that the former state is completed, should be sent to transition. Moreover, the guard function in the transition must be satisfied. For instance, the memory size needs to meet an inequation that the size in need should less than the size exists like Equation (3). The declarations for the CPN model are listed in Figure 14. The CPN model is presented in Figure 15.
The 's' in the color set S is a token marking the state transition of the system. Color set F1 represents whether the failure event occurred, and F2 represents whether the initial state of the system is affected. Once the simulation is initiated, the net runs automatically step by step to send the colored tokens when the guard functions are satisfied.

Simulation Results
The results are listed in Table 2 after the simulation was conducted many times under different conditions. The precondition for each result was that the other constraint set in this net meets the requirements for finishing the simulation, except the condition pointed out in Table 2. The 's' in the color set S is a token marking the state transition of the system. Color set F1 represents whether the failure event occurred, and F2 represents whether the initial state of the system is affected. Once the simulation is initiated, the net runs automatically step by step to send the colored tokens when the guard functions are satisfied.

Simulation Results
The results are listed in Table 2 after the simulation was conducted many times under different conditions. The precondition for each result was that the other constraint set in this net meets the requirements for finishing the simulation, except the condition pointed out in Table 2. Real-time constraints for system state transition is not satisfied. The simulation not running, T1 is not fired The system is in a fault propagation state and not fit for reconfiguration.

5
There is no 'w' sending to the place named Data (Figure 16d) Value of guard function [p = w] is false. W is not fired. Simulation stop A demanding mark is not written to data. components, so the next state failed to share the data.
1. Condition 1: All the constraints are satisfied. The system model obtained when the simulation is conducted for 58 ms is shown in Figure 16a. This model is very similar to the original system model ( Figure 15).

2.
Condition 2: Constraint of the memory size is not satisfied. The simulation will stop running when it runs for 48 ms, because the guard function [m ≤ mem_size] is not satisfied. The upper limit of the system memory size mem_size is only 70 M, but the state needs to occupy a memory size of 70.1 M, so the simulation ends. The result is shown in Figure 16b.

3.
Condition 3: Real-time constraint for the system state transition is not satisfied. By comparing the time consumed and real-time requirements, it can be shown whether the real-time constraint is satisfied. 4.
Condition 4: System state constraint for dynamic reconfiguration is not satisfied. When the system runs to transition T1, it can be judged by the guard function [f1 = failure1 and also I = (s, nofailure2)]. If fault propagation occurs before system reconfiguration and other modules are affected, the reconfiguration scheme cannot be adopted. The reconfiguration process stops and cannot be conducted, as shown in Figure 16c. 5.
Condition 5: Ability constraint for sharing data resources is not satisfied. When the system performs an operation of a shared data resource, if the forward state backup cannot write to the data component, then the checking of the data component and latter state are not triggered. Then, the process stops at a step of 15 ms, as shown in Figure 16d.

Conclusions
Existing studies on dynamic reconfiguration have rarely focused on the process hazard analysis. In this study, a new model-based analyzing method with multiple constraints for the IMA dynamic reconfiguration process was proposed, which is the main contribution of this study. The analysis method is conducted in three steps-modeling, model transition, and simulation. A new model

Conclusions
Existing studies on dynamic reconfiguration have rarely focused on the process hazard analysis. In this study, a new model-based analyzing method with multiple constraints for the IMA dynamic reconfiguration process was proposed, which is the main contribution of this study. The analysis method is conducted in three steps-modeling, model transition, and simulation. A new model method based on AADL was applied to model the dynamic reconfiguration process, and a transition turns the model to CPN for simulation. Several constraints concentrate on few different aspects for the simulation work. This approach was demonstrated using a four-module IMA system. The results of the case study showed the effectiveness of this method. The model-based analysis method with multiple constraints for the IMA dynamic reconfiguration process was proposed in this study, and helps to solve safety issues in the IMA dynamic reconfiguration caused by high integration and complexity.
In the future work, more constraints need to be supplemented for a more comprehensive analysis. If the system becomes more complex and the number of the state of dynamic reconfiguration explodes, it will be more difficult for the analysis work. A high workload occurs due to analysis. Thus, a tool for adding the constraining conditions automatically needs to be developed. The verification of this approach with more complex cases and engineering practices is required.

Conflicts of Interest:
The authors declare that there is no conflict of interest.