Formal Verification Method for Configuration of Integrated Modular Avionics System Using MARTE

,


Introduction
Integrated Modular Avionics (IMA) [1,2] represent realtime computer network airborne systems, which consist of a number of computing modules capable of supporting numerous applications of differing criticality levels.The IMA concept proposes an integrated architecture with application software portable across an assembly of common hardware modules.How to design and analyze an IMA system effectively is becoming one of the most important challenges in the domain of complex embedded system engineering in recent years.
ARINC653 specification [3,4] is one kind of standard for IMA system implementation, and the configuration information of IMA system includes almost all details of the whole system architecture to make IMA system work correctly and reliably.The configuration information in IMA system is usually according to ARINC653 standards.It includes all the data information of abstract levels in system architecture, which can be used to configure the parameters of the IMA system such as hardware resources, the operating system interface, and the environment of application.Even more, when the hardware and software on computing platform change, we can only adjust system configuration information so that existing applications can effectively run on the new platform with consistency.Therefore, how to ensure the correctness of the system reconfiguration information is one of the key problems in the IMA/ARINC653 system design and maintenance.Since the schedule information of IMA is included in the system configuration information, the schedulability analysis needs to be checked within the configuration context.
Model-driven engineering (MDE) [5][6][7] is the mainstream methodology in the domain of system engineering and software engineering for the past ten years.Its basic idea is concentrating on system model design, model transformation, and model analysis and verification, to improve the capability and efficiency of development and maintenance of a complex engineering system.In the DO-178C, which is the latest version of airworthiness standards for aviation software, requirements of both a model-based development and formal methods have been officially proposed [8][9][10].MARTE (Modelling and Analysis of Real-Time and Embedded Systems) [11,12] is a real-time system modelling and analysis language published by Object Management Group (OMG), supporting modelling and analysis of functional modelling for design of complex real-time systems with consideration of time constraints, resource allocation, other nonfunctional properties, and so on.
In this paper, we focus on modelling and formal verification of configuration information of IMA/ARINC653 system based on MARTE.The remainder of the paper is organized as follows.In Section 2, we present an introduction of the typical IMA/ARINC653 system architecture, ARINC653 configuration information, and MARTE modelling elements.Section 3 defines semantic mapping from key concepts of configuration (such as modules, partitions, memory, process, and communications) to components of MARTE element and proposes a method for model transformation between XML-formatted configuration information and MARTE models.In the next section, a formal verification framework of ARINC653 configuration based on MARTE models is given, and Section 5 discusses a schedulable and validation approach of ARINC653 partition system.Also, we design a hierarchical scheduling strategy with consideration of characters of the ARINC653 system, and a scheduling analyzer MAST-2 [13,14] is called to implement a hierarchical schedule analysis.In Section 6, we design a prototype tool called CC653 (Configuration Checker for ARINC653) for modelling and verification of the ARINC653 configuration file [15].Finally, we give two examples to illustrate the effectiveness of our method.

ARINC653 and MARTE
2.1.ARINC653 System.The IMA architecture of an ARINC653 system is shown in Figure 1, which consists of several layers from top to bottom, that is, application software, ARINC653 interface, real-time operating system, hardware interface, and devices.Except those functions implemented by application software, an ARINC653 system module mainly provides mechanisms for execution of a safety-critical software, including partition management, process management, memory management, timing management, interpartition communication, intrapartition communication, and health monitoring.
The right side block of Figure 1 indicates that the configuration information is a very important part of ARINC653 system since it contains many system parameters with consideration of almost all layers from abstractions to real hardware devices.Specifically, ARINC653 configuration information can be divided into two types, module level and partition level, describing the interpartition and intrapartition resource allocation, respectively.Reference [16] introduces a table of configuration information in detail, including 13 module-level entries and 16 partition-level entries.In Table 1, we give an example of general configuration parameters of the module-level in which exactly one entry should be contained for each IMA module configuration.Data form of configuration information can be in different kinds formats, such as XML, Excel, and CSV.In our works, we consider configuration information with the XML format which is recommended in the standard ARINC653 specification [3,4].
One of the main purposes of usage of configuration information is to improve portability and reusability of the IMA system; that is to say, people wish that an IMA system can be adapted quickly by reconfiguring existing configuration information to satisfy new requirements comparing with traditional federal avionic system, for example, when some resource allocations are changed, or some hardware substituted, or new application modules added.However, even if the system configuration can be descripted in a structured way by XML format, large numbers of entries in a real IMA system (maybe thousands of entries) challenge the maintenance of system configurations.It is necessary to find effective ways to ensure the correctness and integrity of the IMA system reconfigured, such as allocating more memory to a new added partition when free memory in the system module is not enough, which is an implicit safety problem that may not be discovered easily in the stage of reconfiguration, and warranting schedulability when a new partition is added or some time frame are adjusted due to changes in requirements.In addition to the size of system configuration mentioned, many factors also need to be considered since changes in the different types of configuration data may influence each other.It is not feasible to carry out overall validations of configuration information by manual inspection, especially in the case of reconfiguration.Therefore, we need a systematic framework to check IMA configuration information based on some standard models and processes.[11,12] (Modelling and Analysis of Real-Time and Embedded Systems) is a domain-specific modelling language for specifying and analyzing real-time and embedded software applications and systems.MARTE is also becoming one of the industry standards in embedded system domain.In fact, it is one kind of complement standard of UML by refining standard UML concepts with more exact semantics interpretation for real-time computing.As shown in Figure 2, those elements of MARTE specification are structured around three main aspects: MARTE foundations, MARTE design model, and MARTE analysis model.

MARTE. MARTE
In brief, the foundation package in Figure 2 is used for description of basic concepts in a real-time and embedded system, such as priority, response time, execution cycle, and resource constrained.It is not only the foundation of the design and analysis model but also the core of the MARTE specification.The design model package provides modelling elements of higher abstraction layer, used for modeling the 2 International Journal of Aerospace Engineering behavior of concurrent and real-time activities.The analysis model encapsulates model elements to analyze the performance and reliability of the system, specifically for energy consumption, memory usage and availability, reliability, and safety of the system.The design models and analysis models should be established by reusing the foundation concepts.These modelling and analysis mechanisms in MARTE provide a good way to analyze and check the IMA system configuration information.

Modelling ARINC653 Configuration with MARTE-2
In order to build MARTE models from ARINC653 configuration information, we need to define semantic mapping rules from different types of items in the ARINC653 configuration to MARTE model components, properties, or other modelling elements.Then we can design a systematic way for configuration modelling (it is also called a process of model transformation in this section).Since the details of IMA configuration are quite complicated, considering that all configuration information of the ARINC653 system in one time is not feasible, in this paper we just focus on how to build MARTE models for key concepts in the ARINC653 system (such as module, partition, process, partition communication, and health monitor) by establishing model transformation rules and corresponding examples.

Rules of Module Transformation.
The "module" concept in the ARINC653 system refers to a computational node in an airborne computing network, in which several different application software are deployed and the real-time operating system conforms to ARINC653 specifications.Specifically, a module part of the configuration contains the descriptions of a processor, communication interface, memory, and other resource allocation of hardware, also including partition information of avionics application execution in the module.However, configuration information related to the inside of partitions is not included in this so-called "module-level" configuration.The typical module configuration data includes the system resource allocation for each partition and the partition-level scheduling strategy.Based on the semantic analysis, we can use the "hwProcessor" component in the MARTE specification to model those configuration information.The "hwProcessor" component specifies the runtime execution environment, including CPU scheduling, memory allocation, and BUS of communication connection.For instance, the name of a module (Module Name) can be defined by using a MARTE component attribute (descrip-tionHwProcessor) and module scheduling time slice (Major Frame) can be described by defining the component attribute (mainScheduler).Table 2 shows the module transition rules.Figure 3(a) is a small example of the module configuration part of ARINC653 system in XML data.Generally, it includes two parts: partition information and scheduling information.The partition information specifies each partition information (partition name, partition ID), and the example module contains two partitions, named Part1 and Part2.The scheduling information specifies that the

Rules of Partition Transformation.
The "Partition" concept in the ARINC653 system is one of the key components of IMA.It requires that a set of avionics applications implementing different functions are integrated in the same module; the system management should make each software application running in respective partition in an independent way except for necessary communications among those partitions.That is to say, all partitions should be isolated one by one both in the dimension of time and space.Time isolation means that execution of different partitions should not interfere with each other in the corresponding configuration part of allocation of execution time on the module platform; for instance, scheduling cycle and execution time for each partition need to be preconfigured very carefully.Spatial isolation demands that different partitions should be assigned to different memory address, even in the stage of running time.
In MARTE specification, there are no concepts corresponding directly to the partition concept of ARINC653 system, but we can combine swSchedulingResource and ProcessingResource components together, also their attributes, to descript the configuration information of an IMA partition.For the time and space characteristics of a partition, we use the memoryPartition component in MARTE to indicate contents of the partition (such as thread and data).We also put swSchedulableResource component to be included inside of memoryPartition component in MARTE.The relationship between these two components can be defined by Allocate, and the value of attribute nature is spatial distribution.
In addition, the concept of Memory in ARINC653 specification denotes demands of memory allocation on one module and also gives memory requirements for each partition in which each memory space is independent without affecting each other.Correspondingly, the hwMemory component in MARTE indicates system memory allocation information (such as size and category).The hwProcessor component can combine swSchedulingResource and hwMemory components together through setting its ownedHW attribute properly.At the same time, this binding points out the allocation of memory of swSchedulingResource component.Therefore, we can convert the ARINC653 memory directly to hwMemory component in MARTE, by defining a subcomponent hwMemory for each memoryPartition component to indicate the spatial isolation conditions in each partition on the same module.So, partition transformation rules are given in Table 3.
Figure 4(a) is an example of the partition configuration part of ARINC653 system in XML data.It contains two parts of partition information and memory information.The partition information indicates the name and ID of a partition and memory allocation information of the partition is required (such as a BSS segment size of 0 × 10,000 and TEXT segment size of 0 × 40,000).Then the transformation from XML configuration to a MARTE model is shown in Figure 4(b), in which "ownHW" points out the memory information required.

Rules of Process Transformation
. "Process" in the ARINC653 system is a dynamic execution concept of application just like in a general system.It contains executable codes, application data, and resource of stacks.But ARINC653 defines that a process should be assigned in only one partition and one partition can contain multiple processes to complete the corresponding application functions.Inside of an isolated partition, there is another world, in which we can define process-level scheduling strategy (such as preemptive scheduling strategy), maximum response time, memory allocation, and other information, to control the execution of processes.For the purpose of modeling the  4 International Journal of Aerospace Engineering process concept of ARINC653, we consider swSchedulingResource component in MARTE which is defined as the most basic execution unit of the system triggered through the time period or external events, and also, the communications between threads can be described by port connection, subroutine calls, and shared data.Since they have the same semantics of executable units of a system, we can convert the process of ARINC653 to the swSchedulingResource component of MARTE.Those characteristics of an executable unit can be defined through MARTE element attributes, including execution cycle, execution deadline, execution time, and scheduling strategy.Considering that a process is included in some partition, we included the swSchedulingResource component in the ProcessingResource component by relationship.Process transformation rules are given in Table 4. Figure 5 is an example of process configuration transformation from part of the ARINC653 system in XML data to a MARTE model.

Rules of Health Monitoring
Transformation.The health monitoring mechanism of ARINC653 system is one of the characteristics of IMA, which is responsible to detect, report, and control abnormal system behaviors in case some hardwires or software failure occur.In a safety-critical avionics   The type of ownedHW is hwMemory 5 International Journal of Aerospace Engineering application, any kind of fault occurrence should be detected in time and need to be isolated by a predefined strategy; furthermore, some recovery actions ought to be taken.According to the scope affected by faults, ARINC653 divide those faults into three levels: module, partition, and process.Also according to the cause of faults, multiple types of faults are further defined, for instance, floating-point error, stack overflow, and hardware error.Obviously, the error handling mechanisms are different (e.g., module restart, cold start, and warm start) due to different levels of faults.
In MARTE specification, there are also no concepts corresponding directly to the health monitoring of ARINC653 system, but we can add some new attributes of HM ERRORS and HM Actions for hwProcessor, memoryPartition, swSchedula-bleResource, and ProcessingResource components in MARTE, which are corresponding to the module recovery action HM Module Recovery Actions, the partition recovery action HM Multipartitions Actions, and the process recovery action HM Process Recovery Actions.Specifically, HM ERRORS defines fault types and HM Actions defines recovery actions.These attributes can be included in different components to represent different levels of ARINC653 system faults.Health monitoring transformation rules described above are given in Table 5.

Rules of Partition Communication Transformation.
Intrapartition communication refers to the interactions among those processes assigned in the same partition.Intrapartition communication mechanisms generally include buffers, blackboards, semaphores, and events.Buffers and blackboards provide general interprocess communication (also synchronization), whereas semaphores and events are provided for interprocess synchronization.All intrapartition message passing methods must ensure atomic message access (for instance, partially written messages should not be read).
Since existing data in message queue will not be replaced by a new one of the next communication and ClientServer-Port component in MARTE exactly has the same semantic concept of buffer, we can convert a message queue (also called a buffer) of ARINC653 to a ClientServerPort component in MARTE which contains an attribute of data.Specifically, if the values of attribute kind and isAtuomic are provided and true, respectively, the ClientServerPort component will write data into the buffer; if the values of attribute kind and isAtuomic are required and true, respectively, the ClientServerPort component will read data from the buffer.Similarly, because the blackboards do not retain the last communication data, it can be converted to flowPort component of MARTE which represents the signal mechanism of ARINC653, and we can define the concurrent mechanism by adding attribute Concurrency Control Protocol to those components.
The interpartition communication is intended to facilitate communications between different ARINC653 application partitions residing on the same module or on different modules of a network.All interpartition communication is conducted via message passing.The basic mechanism linking partitions by messages is the channel.A channel defines a logical link between a message source and one or more destinations, and it also specifies two modes of message passing: sampling mode and queuing mode.In the sampling mode, a message remains in the source port until it is transmitted by the channel or it is overwritten by a new occurrence of the message; this allows the source partition to send messages at any time.In the queuing mode, each new instance of a message may carry uniquely different data and is not allowed to overwrite previous ones during the transfer.No message should be unintentionally lost in the queuing mode.
We can convert the queuing mode port to the ClientServer-Port component of MARTE which has the capability of receiving a set of data, inserting into a queue, similar to the characteristics of queuing mode in ARINC653.The sampling mode port is converted to a flowPort component.FlowPort has no data queue, and it has same communication semantic of sampling mode in ARINC653; that is, the <Partition Name="Part1" Id="1"> <MemorySize MemorySizeBss="0x10000" MemorySizeText="0x40000" MemorySizeData="0x10000" MemorySizeRoData="0x10000"/> … </Partition> </Partition ="Part2" Id="2">… </Partition>   International Journal of Aerospace Engineering last received data will be discarded when the next data arrived.The partition communication transformation rules described above are given in Table 6. Figure 6(a) is an example of part of the partition communication configuration of ARINC653 system in XML data.It contains two kinds of configuration of partition and communication.The partition information specifies each partition setup (partition name, partition ID, and so on) and communication ports of partitions.For instance, partition Pr2 has a sampling port named "pdatain": the port refresh frequency is 0.025 seconds and the type is destination port.Partition Pr1 has a sampling port named "pdataout": the port refresh frequency is 0.015 seconds and the type is source port.The communication information indicates each channel setup; this example contains only one channel.The source port of channel is "pdataout" port of pr1, and the destination port of channel is "pdatain" port of pr2, thus establishing a data stream communication connection.The transformation of MARTE model of the configuration information specified in Figure 6(a) is shown in Figure 6(b).Sampling refresh period points out the refresh frequency.

Modeling of Communication Virtual Link.
Virtual link is a virtual logical link consisting of one to many sublinks, which mainly provides bandwidth resource isolation function.It is established through communication between different terminal nodes in AFDX network.The bandwidth resources of virtual links are guaranteed by some parameter setting, such as the length of the data frame, the gap of the bandwidth allocation, and the data transmission mode.The CommunicationMedia (CM) component in MARTE can represent the data transmission between the source terminal and the destination terminal, so the elementSize property in the CM component can represent the length of the data frame in a virtual link, using the capacity properties and ele-mentSize attributes in the CM component to represent the bandwidth allocation gap parameters in the virtual link and using the transmMode attribute in the CM component to represent the data transmission pattern.There are three main modes of transmission: simplex, half-duplex, and full-duplex.Figure 7 is an example of a communication virtual link MARTE model, which shows the property of data transmission between RDC and switch virtual link.The transmission data frame length is 11, the transmission capacity is 100 Mb/ s, and the transmission mode is full-duplex.

AFDX Terminal
Modeling.The AFDX terminal system provides the communication access port of the device to the AFDX network and is responsible for completing the communication tasks from the partition or equipment and sending and receiving the data.The terminal system sets relevant parameters according to the communication requirement and the data frame size in the communication link, including the parameters of the maximum data frame length and the minimum packet gap.The CommunicationEndPoint (CEP) component in MARTE represents the interface of communication elements passing through CM components and contains only one attribute packetSize, which matches the elementSize attribute in CM components.Therefore, the CEP component in MARTE is used to represent the AFDX terminal, and the packetSize attribute in the CEP component is used to represent the data frame size parameters of the terminal and the communication link.
As shown in Figure 8, the AFDX terminal module provides the communication access port from RDC to AFDX switch.The AFDX terminal is represented by the CEP component.The property packetSize represents the size of the transmission data frame and is consistent with the element-Size of the data frame size in the communication virtual link.

Modeling of Resource Equipment
Module.The resource and device modules in IMA system include core processing module IPM, remote data concentrator RDC, AFDX switch, and a controller.Each module has its own independent processing unit to perform corresponding functions.IPM provides computing resources for applications that are residing in the partition, and AFDX switches provide communication resources to provide message forwarding function, and RDC is used as avionics input and output device for data collection

A Framework for Verification of ARINC653 System Configuration
Based on the above modeling rules for ARINC653 system configuration by transforming the XML format configuration data to corresponding MARTE elements, in this section, we propose a formal framework for verification of safety properties which should be considered during the stage of ARINC653 configuration design and maintenance.Figure 7 shows the main steps in this framework in which an open source environment Ocarina [17,18] and a theorem proof tool are applied.Since up to now there are still no formal model verification techniques which can be directly applied to MARTE models, we have to transfer those MARTE models into corresponding AADL models which are inputs of Ocarina (those transformations rules can be referred to [12,19]) for the purpose of applying the theorem proof tool effectively.In our future works, we will consider to establish formal analysis techniques directly addressing the MARTE models.In Figure 10, another input of Ocarina is safety properties of ARINC653 system configuration which are described in logic-based formal language REAL (Requirement Enforcement Analysis Language) [20].
Requirement Enforcement Analysis Language (REAL) is a kind of model checking language applied in specification and architecture design stage to analyze the validity of       International Journal of Aerospace Engineering Spatial Isolation.Memory must be allocated individually for each partition and so on.
Memory Allocation.The stack space, data space, and code space occupied by processes and threads in partition must be less than the application in the partition configuration and so on.
Health Monitoring.Health monitoring must ensure that each potential fault is banded with a corresponding recovery action, and a hierarchical structure of each level (module, partition, and process) should be associated with all kinds of recovery action and so on.
The following are the descriptions of safety properties of ARINC653 configuration with the form of REAL theorems.

Time Constraints.
In brief, time constraints need to verify two kinds of constraints: the first one is that each partition of an ARINC653 module must be scheduled one time in each scheduling period and the second one is that the sum of all partition scheduling slices should equal to the time period of the module allocated.Figure 11 shows an example of second constraint, that is, the MARTE property Module Major Frame indicates the period of module-level schedule, and Partition Slots is a list of values, indicating time allocations for each partition in a module.What we need to check is whether each ARINC653 module of the Partition Slots value equals the value of Module Major Frame.

Spatial Isolation. Property of spatial isolation in essence
needs to verify that one specific segment of memory should only be assigned to one partition which is shown as a REAL theorem in Figure 12.Specifically, Figure 12 identifies the main memory component of the system that is variable minimum, and then obtains all its subcomponent of memory, that is variable partmen.Finally, we get each subcomponent and assign them to the process component.What we need to check is whether the number of process component elements is equal to 1, for instance, one memory segment must be assigned to one partition.

Memory Allocation.
Memory allocation involves lots of issues.It just gives an example of basic safety property as mentioned before: the stack space, data space, and code space occupied by processes and threads in one partition must be less than the application in the partition configuration.Figure 13 shows the corresponding REAL theorem which firstly identifies all threads in a process of one partition and finds out the necessary memory quantity of the partition process, that is, variable MEMS, then we need to check whether the stack space, data space, and code space occupied by processes and threads in one partition is less than the application in the partition configuration.

Health Monitoring.
Example of property of health monitoring includes two kinds of constraint: the first one is when an error occurs inside a partition; it should not affect other partitions even if there are existing data communications between partitions.The first way to achieve this objective is for the receiver partition to be assigned to a lower critical level than the sender partition as shown in Figure 11.The second one is that faults inside ARINC653 system are divided into three different levels: module, partition, and process; one specific fault should be detected and covered at least in one level of the three.
Figure 14(a) shows the REAL theorem example of the property of health monitoring.Firstly, the theorem gets the ARINC653 partition execution environment by using function calls of communication in the system partition, then checks whether the value of Criticality (representing the partition critical level) of destination partition is less than the value of sender partition.Figure 14(b) also shows the second constraint of example, that is, by firstly getting the information of partition which contains the ARINC653 process to be analyzed and also the corresponding execution environment of the partition, then getting the module which contains corresponding partitions.After that, we need to check the fault list (the attribute is HM ERRORS) of the ARINC653 process, partition, and module and determine whether its critical level is according to the default fault list.

Schedulability Analysis of ARINC653 Module
After getting the MARTE model with the concept of time behavior related to the IMA system, we constructed the corresponding MAST-2 text model according to the MARTE model of the system and verified the schedulability of the system based on the MAST tools.The analysis 5.1.The Feature of Schedule Model for IMA System.In the IPM module of the IMA system, there are multiple application partitions and system partitions, each of which contains a set of respective execution tasks.In the IPM resource configuration phase, the CPU time resource will be allocated to each partition, and the allocation is carried out in the form of a time slice.The execution of all the partitions themselves and the tasks in the partition need to meet the allocated time slice constraints; here, the time slice contains two parameters, offset and duration.If the time slice's corresponding time is finished, the current operation will be interrupted until the next time slice is allocated to continue the corresponding task.Corresponding to partitions in between and tasks within the partition, the IMA system scheduling model consists of two level scheduling strategies, which are interpartition scheduling and intrapartition scheduling, respectively, as shown in Figure 15.(e) At least all partitions are assigned to one partition window.

Operation Model
Elements.The Operation model element describes the processing capacity range of a computing task or message transmission execution, including the time range of task execution and the range of message size.The subtypes of Operation include Code_Operation and Messa-ge_Operation, which describe the processing of computing tasks and message delivery, respectively.Table 10 describes the MAST-2 model for performing the processing capabilities of a computing task Task1 and message transfer nettask1 in the IMA system.

End_To_End_Flow Model Elements
. End_To_End_-Flow model element describes the system implementation of activities triggered the relationships between conditions in a series of events, including three types, which are external event External_Events, internal event Internal_Events (including time requirement), and event processor Event_Handlers.The End_To_End_Flow model element can be used to describe the IMA partition scheduling model.Entry events belong to external events, its type is Periodic, and express that major time slicing is periodic distribution; the end event belongs to the internal event, its hard global deadline can represent the rotation cycle of major time slice of the partition scheduling, and the time slice of each partition is set between the entry event and the end event, and there is a Hard global deadline to represent the available time slices of the partition, respectively.The corresponding MAST-2 model description is shown in Table 11.

IMA System Schedulability Verification Framework.
According to the characteristics of IMA system partition scheduling, this paper proposes a schedulability decision method based on the third-party tool MAST simulation method for IMA system time resource configuration verification.To aim at MARTE model for time resource configuration behaviors of system, the corresponding MAST-2 model text file can be constructed.At the same time, because the MAST scheduling strategy is scalable, we can choose the 13 International Journal of Aerospace Engineering custom scheduling strategy according to requirements, such as adding relevant time constraints information into MAST-2 model files, and then using MAST tools for further schedulable analysis.Finally, we get the schedulability decision results and scheduling simulation Gantt chart.The concrete method framework is shown in Figure 16.We will give a specific example analysis on the IMA airborne water processing subsystem in Section 7.2.International Journal of Aerospace Engineering are available, the data form is complete or not, and return the relevant error tips for the user.The verification results in dynamic displaying module will show users the multidimensional verification results, such as scheduling simulation results and scheduling simulation Gantt chart.
(2) The business layer is responsible for processing those instructions coming from the application layer, for instance, the transformation from XML formatted configuration information to MARTE models.On the other hand, data processing of the persistent layer are completed in this level.And business layer also needs to provide scheduling strategies and verification documents to the application layer.
(3) The persistence layer manages different kinds of data, such as reading the configuration file, accessing the MARTE model file, and generating the MAST-2 file.
The execution process of CC653 is described in Figure 18.Firstly, we need to parse the configuration file in XML format and save the corresponding MARTE model transformed according to the modelling rules.Then REAL theorems for safety properties of system configuration are constructed through requirement constraints, and the theorems are imported into Ocarina to verify with MARTE models.For schedule analysis, CC653 continue to convert information of task sets in MARTE configuration model into text format which can be identified by MAST tool, also custom schedule strategy.Finally, verification results and the corresponding error messages are output through the user interface.We can group those process steps into three modules as follows.
The module of configuration information model generation provides functions including ARINC653 configuration information (XML format) editing and parsing: (1) MARTE model generation, configuration information conversion rule management, verification function selection, and other functions.The user can view the ARINC653 configuration information according to the integrated XML tool, and also display and analyse the converted MARTE model.
(2) The module of configuration information correctness verification provides the functions including viewing REAL theorems and calling Ocarina model analysis suite to analyze and verify the MARTE model generated from the module of configuration information model generation.
(3) The module of partition schedulability verification provides the functions including modelling the scheduling information, the conversion of MARTE model to the text recognized by MAST, and calling mast tool to check the schedulability of the converted model.

Case Study
7.1.Example of General Configuration Verification.Table 12 describes a partition scheduling information of ARINC653 module; Table 13 is a part of the XML configuration file which contains the configuration information Table 7 described.The total scheduling period of the current module is 0.2 seconds, it contains 5 partitions.The table and figure specify the starting time and execution time for each partition, that is, the starting time and size of the corresponding time window.According to the model transformation method, we firstly convert the ARINC653 system configuration information illustrated in Figure 19 into MARTE models.Figure 19 partly shows the MARTE model.Partition P1, P2, P3, P4, and P5 were converted into the virtual processor component partition 1, partition 2, partition 3, partition 4, and partition 5; the allocation partition time slice are expressed in attribute slots allocation and partition slots.The former one specifies the sequence of partitions occupying the system clock and the latter one specifies the size of time slice.For the idle duration of system clock, there is no partition occupying the system clock, so firstly a free partition (partition idle) can be created, then the corresponding time slices are allocated to that partition.
Then we need to prepare REAL theorems according to the safety requirements to be verified.Considering that the example configuration described in Table 12 contains time information, we need to verify the time constraints of system partition.Here, we use the theorem (depicted in Figure 11 of Section 4) to check whether the size of module time slices are equal to the sum of partition time slices, and save the verification theorem as a file with the extension of "real."After that, we use the Ocarina tool to analysis the model and the result of output is shown in Figure 20.In that snapshot of 15 International Journal of Aerospace Engineering processing, the arinc653.realis a file name of the REAL theorem, and ARINC653 system is the input file name of Ocarina which corresponds to the MARTE configuration model.
The results of the primary analysis shows that the configuration contained in Table 12 is satisfied with the requirement of time constraints, namely, in a module scheduling period, the sum of partition time slice is less than or equal to the total of module time slices, so the verification process returns true (shown in Figure 20 that theorem resource is TRUE).However, an ARINC653 module maybe under reconfiguration in the stage of system maintenance; for instance, we may need to add a new partition P6 on the current module to support some new functions.The scheduling information of P6 after reconfiguration is shown in Table 14; that is, we add the allocation of time slice to P6.Now we should have to verify the time constrain of the reconfiguration file once again.After second verification process, we found that the configuration information contained in Table 14 is not satisfied with the requirement of time constraint, namely in a module scheduling period, the sum of partition time slice is greater than the total of module time slices (the sum of all data in line "window duration" is greater than 0.2 seconds), the results return false, which means that the configuration needs to adjust more carefully.

Example of Partition Schedulability.
In this section, we will give an example of modelling the partition system schedule information with MARTE and the ARINC653 system In the aviation specification ATA-38, the main functions of the airborne water-and-waste (WAW) system are described, including the storage and transmission of clean water, storage, and removal of sewage.
Figure 21 gives an overview of the physical structure of the WAW, which contains two tanks for storing drinking water and sewage.Two signal controllers are also included in the system.Each controller contains a sensor and an actuator.The main functions of the system are scheduled to run on the IMA platform in the form of a partition application.Its main functions include calculating the available space, calculating the equilibrium state of the aircraft, and controlling the valve and the information of the output state to the cockpit.In addition, the current system parameters will be displayed in a cockpit display.
Figure 22 describes the structure of the hardware resource network of the WAW system.This architecture is based on the requirements of the high-level system and the information of the IMA platform.Two signal controllers in the figure are used to detect the various signals of the storage tank in the WWS system and then transmit it to the corresponding RDC (Remote Data Collector) in the form of analog signals.Another two RDCs are connected to those signal controllers and AFDX switches, respectively.The function of RDC is to convert and transmit the digital and analog signals.And two AFDX switches connect those devices into the AFDX network.An application partition and a system partition are scheduled to run in the IPM (Integrated Processing Module).In the application partition, the current system state is calculated based on the received data, and the control command is sent.The function of the system partition is mainly to monitor the whole system and the communication of the virtual link among different devices.
Table 15 shows schedule information of an interpartition and intrapartition task set in a WAW system.Papp denotes the application partition and Psys denotes the system partition.The main schedule framework duration is 10 ms.And scheduling strategy could be EDF and DMS.The time slices for partitions are 6 ms and 4 ms, respectively.For each partition, all kinds of task set parameters are included in the table: task, cycle, execution time and deadline, and so on.
According to the method given in the third section which shows how to transfer an IMA system into a MARTE model, we can establish the MARTE model of WAW system, as shown in Figure 23.
In this MARTE model, the hwProcessor and hwDevice components represent the AFDX switches, RDC, and signal controllers in the WAW system.The hwProcessor and MutualExclusionResource components represent the IPM processor module.The system partition and application partition in IPM are represented by the combination of swSche-dulingResource and ProcessingResource components and related attributes, respectively.Each partition has two tasks and its scheduling properties are described with swSchedu-lingResource components.Finally, the time constraints corresponding to each task are represented by TimeConstraint component, including time slice and deadline.
The results of the analysis of the WAW's MARTE model by using MAST are shown in Figure 24.The left part of Figure 24 is the result of the schedulability analysis of the time resource configuration.It can be judged from the result that time resource allocation in the table can satisfy the requirement of WAW system, and there will not be any partition or process without being scheduled.The right part of Figure 24 is the Gantt diagram analysis for the scheduling simulation.From this diagram, according to the above time configuration, all processes and tasks can be scheduled, and there are no time window overlaps.In the process of IMA system resource configuration, time resources could be reconfigured because of the changes of requirement of the system.For example, if we want to add an application partition Papp2 in the WAW system, we need to allocate a time slice and other resources for the Papp2.Table 16 shows the modified time resources of all partitions.At this point, the total time framework is still required to be 10 ms.After analysis by MAST, we can find that the allocation of time resources for Papp2 may lead to the situation that the sum of time slices of all partitions are greater than the main time frame.Therefore, this resource schedule framework will not be accepted.

Related Works
The related works are divided into the following four categories: the first one is related to the domain of model-driven engineering methods applied in the development of complex airborne systems in recent years; for instance, [21] introduced a verification analysis method based on modeldriven framework for aviation electronic system and [22] provided a modelling analysis example based on the system modeling language (SysML).The second one is about the research of MARTE and AADL (architecture analysis and design language) [23] in the design stage of complex embedded systems.For example, [12] described the concept of consistency and the mapping relationship between MARTE subset and AADL; reference [19] established the model transformation method between MARTE and AADL.Third, related works include research on the structure and analysis methods for IMA/ARINC6523 system configuration information.For example, reference [24] described a modeldriven development method of ARINC653 configuration table; reference [25] designed an IMA system reconfiguration verification method which is not based on model-driven methodology instead of directly processing configuration data set.The last one of the related works is about IMA system schedulability, that is, including [26] which described how to compute time consumed by the system based on the function of task time requirement and established a decision theorem of system schedulability; the effect of partition parameters on the real-time performance of task scheduling is analyzed by [27].By comparison of the above related     19 International Journal of Aerospace Engineering works, our works proposed a MARTE-based comprehensive methodology for IMA/ARINC653 system configuration modelling, formal verifications, and schedulability analysis and also designed a tool of CC653 which can be used both in the development stage and reconfiguration stage.

Conclusion
In this paper, we focus on modelling and verification of configuration information of IMA/ARINC653 system based on MARTE.Firstly, we define a semantic mapping from key   International Journal of Aerospace Engineering concepts of configuration (such as modules, partitions, memory, process, and communications) to components of MARTE element and propose a method for model transformation between XML-formatted configuration information and MARTE models.Then we present a formal verification framework for ARINC653 system configuration based on theorem proof techniques, including construction of corresponding REAL theorems according to the semantics of those key components of configuration information and formal verification of theorems for the properties of IMA, such as time constraints, spatial isolation, and health monitoring.
After that, a special issue of schedulability analysis of ARINC653 system is studied.We design a hierarchical scheduling strategy with consideration of the characters of the ARINC653 system, and a scheduling analyzer MAST is called to implement hierarchical schedule analysis.Lastly, we design a prototype tool, called Configuration Checker for ARINC653 (CC653), and case studies of configuration of IMA system are provided for demonstration.Future works include the following two aspects: (1) we need to further consider the modelling and verification of those secondary configuration information, and it is necessary to give formal definitions for those transformation rules between ARINC653 configuration data and MARTE models; (2) we need to apply our methods to a real avionics system development to obtain feedback and improvement and also further design formal verification techniques for MARTE model of configuration directly, without using third-party verification tools.

3
International Journal of Aerospace Engineering scheduling time of Part1 is 0.025 s and the scheduling time of Part2 is 0.020 s.Then the XML configuration is transformed to a MARTE model Figure 3(b), in which "Partition Scheduler" pointed out the partition-level scheduling information.

Figure 2 :
Figure 2: The basic modeling elements and structure of MARTE.
Partition configuration information of MARTE

Figure 7 :
Figure 7: MARTE model of communication virtual link.

Figure 10 :
Figure 10: Validation framework of configuration information.

5. 1 . 1 .
Interpartition Scheduling.The interpartition scheduling (called the first-level scheduling) in the IMA system is determined when the IPM resource is configured.Each partition is periodically allocated to a time slice, and the size of the time slice is denoted as duration.The characteristics of interpartition scheduling are as follows:(a) Partition is the basic unit of scheduling.(b)There is no priority between partitions.(c)Interpartition scheduling is repeated in a period of time.(d)Scheduling period is determined by the size of the time slice fixed in IPM resource allocation.

Figure 16 :
Figure 16: Process flow of IMA system schedulability verification.

Figure 19 :
Figure 19: Partition configuration schedule model of MARTE.

Figure 20 :
Figure 20: Result of partition configuration analysis.

Figure 21 :Figure 22 :
Figure 21: Physical structure of the water-and-waste system.

Figure 23 :
Figure 23: A MARTE model for WAW system.

Figure 24 :
Figure 24: The analysis result of MAST for WAW model.

Table 1 :
Example of general configuration information table of ARINC653 system.

Table 5 :
Health monitoring transformation rules.

Table 6 :
Process communication transformation rules.

Table 12 :
Partition configuration schedule rules.

Table 13 :
Partition schedule configuration in XML format.

Table 14 :
Reconfiguration table of partition information.

Table 15 :
Schedule information of WAW system.

Table 16 :
Reschedule information of WAW system (time unit: ms).