MODEL-DRIVEN DEVELOPMENT OF

ARINC 653 CONFIGURATION TABLES

Ákos Horváth, Dániel Varró, Budapest University of Technology and Economics
Department of Measurement and Information, Budapest, Hungary
Tobias Schoofs, GMV, Lisbon, Portugal

Abstract architect with limited tool support that only ease (i)
the manipulation of its XML representation, (ii) their
Model-driven development (MDD) has become
validation to the ARINC 653 schema definition and
a key technique in systems and software engineering,
some consistency checks.
including the aeronautic domain. It facilitates on
systematic use of models from a very early phase of Unfortunately, despite the inherent complexity
the design process and through various model of ARINC 653 configurations, current tools
transformation steps (semi-)automatically generates supporting configuration design offer very low-level
source code and documentation. However, on one support directly on the XML representation level.
hand, the use of model-driven approaches for the However, existing tools lack support for (1) capturing
development of configuration data is not as widely the development process for configurations, (2)
used as for source code synthesis. On the other hand, validating design constraints for configurations on-
we believe that, particular systems that make heavy the-fly, (3) recording explicitly the critical design
use of configuration tables like the ARINC 653 decisions made by the system architect, and (4)
standard can benefit from model-driven design by (i) providing traceability between high-level
automating error-prone configuration file editing and requirements and the configuration tables, which
(ii) using model based validation for early error require hand-crafted traceability lists. As a result,
detection. verification of configuration tables is a tedious
activity.
In this paper, we will present the results of the
European project DIANA that investigated the use of Model-driven development (MDD) has become
MDD in the context of Integrated Modular Avionics a key technique in systems and software engineering.
(IMA) and the ARINC 653 standard. In the scope of It facilitates on systematic use of models from a very
the project, a tool chain was implemented that early phase of the design process. Based on high-
generates ARINC 653 configuration tables from level modeling standards (like UML , SysML [2] or
high-level architecture models. The tool chain was AADL [3]), traditional MDD separates business and
integrated with different target systems (VxWorks application logic from underlying platform
653, SIMA) and evaluated during case studies with technology by using platform independent models
real-world and real-sized avionics applications. (PIM) to capture the system requirements, and
platform specific models (PSM) to specify the target
system on the implementation platforms (ADA, Java,
Introduction C++). PSM may refer to models or to platform-
The ARINC 653 standard [1] has taken a leading specific artifacts like source code and configuration
role within the aeronautical industry in the elements; the latter are automatically generated from
development of safety-critical systems based on the PIM and PSMs, respectively, using automatic model
Integrated Modular Avionics (IMA) concept. One of transformations.
the main promises of IMA is cost saving in reduced
However, as MDD is attracting increasing
development, integration and verification and
attention in safety-critical system development [4],
validation effort.
the original approach needs to be adapted to be in-
In case of ARINC 653 compliant platforms line with the rigid certification requirements (e.g.,
many deployment and implementation details are DO-178B [5]) imposed by authorities.
defined in the configuration tables. Typically, these
configurations are hand defined by the system
 In the paper, we present a framework for development process by introducing precise
systematically designing standard ARINC 653 engineering practices based on formal modeling
configuration tables with additional support for techniques. By this approach, design intelligence is
configuring (i) the Wind River VxWorks 653 Safety applied to capture all relevant information in the form
Critical RTOS [6] and (ii) the GMV SIMA ARINC of abstract models. First, these models can be used
653 simulation platform [7]. Additionally, parallel to for documentation purposes to store well-structured
the development process our approach generates end- information about the system-under-design.
to-end traceability information to support Moreover, models can also be used for generative
certification Our toolkit is implemented in the development, where target design artifacts (source
Eclipse framework, and it is built upon the principles code, configuration tables, test cases, textual
of Model-Driven Development (MDD). documentation, etc.) is (semi-)automatically derived
by tools. Finally, models can also be used for early
The framework was developed in the context of
validation, where important properties of the
the DIANA [8] project financed by the European
products (such as reliability, performance,
Commission through the Sixth Framework
robustness, security, complexity) can be evaluated
Programme in close collaboration with leading
before actual implementation begins. All of these
avionics experts and airframers including GMV,
techniques aim at reducing costs and risks.
AleniaSia, Atego, Dassault, Embraer, NLR,
THALES, and academic partners of TU Budapest MDD emphasizes the clear distinction between
and Karlsruhe Institute of Technology. Platform Independent Models (PIM) and Platform
Specific Models (PSM), thus, software development
in MDD is envisioned as a three-step process.
Outline
First, the Platform Independent Model (PIM)
In order to introduce our approach we (i) outline
is designed. The main purpose of this model is to
the basics of model-driven development for safety
capture the underlying business logic without specific
critical system, (ii) presents our intermediate models
implementation details and, this way, help portability
and target platforms (iii) give a motivating air
to other target platforms (e.g., a prototyping
conditioning case study, (iv) introduce our PIM-PSM
platform, using Java, for instance; the final target
mapping approach, (v) highlight a contract based
platform, ARINC 653 for the aeronautical world or
V&V approach and finally (vi) conclude the work.
AUTOSAR [9] for the automobile domain based on
ADA or C).
Model-Driven Development for Safety The second step is to generate a Platform
Critical Systems Specific Model (PSM), which contains additional
Models are prime artifacts of engineering. In models, and represents an implementation of the
system development, they have played an important system under design which can run on the target
role as a way to capture real world notions as well as platform. The transition between PIM and PSM
abstract constructs. In fact, system architects have (PIM-PSM mapping), should typically be facilitated
been using models and modeling techniques long using automated model transformation technology.
before model-driven development emerged as a Finally, software artifacts (e.g., configuration
trend, e.g. in the form of entity-relationship diagrams, files, source code, documentation, etc.) are
graph-like data structures, abstract syntax trees etc. generated from the Platform Specific Model for the
However, the term Model-Driven Development target platform. Again, code generation should be as
(MDD) implies that models play a central role that extensive as possible, in order to minimize the
encompasses the entire system development amount of necessarily slow and error-prone manual
lifecycle, starting from requirement analysis, system coding. This, in turn, requires PSMs that are
design, implementation, to verification and even expressive enough, not only from a static, but also
maintenance. from a dynamic point of view of the system, to
Model-driven development aims to increase the produce all of the application artifacts.
efficiency and productivity of the software
Enabling technologies Challenges in MDD for Safety Critical Systems
MDD relies on two key technologies that allow In order to support the specific needs of the
the definition and manipulation of models called, safety-critical development processes, we followed
metamodeling and model transformation, the guidelines introduced in the EU-FP7 INDEXYS
respectively. [15] project for the definition of a MDD means for
Metamodeling is a methodology for the embedded systems. Based on these guidelines the
definition of modeling languages. A metamodel main challenges of MDD for safety-critical systems
specifies the syntax (structure) of a language. are the following (depicted in Figure 1.):
Metamodels are expressed using a metamodeling V&V activities need to be tightly integrated
language that itself is a modeling language. The [16] into the development process to provide early
metamodel can also be interpreted as the object- feedback on requirements, specification, design and
oriented data model of the language under design. implementation. This requires a continuous
There are several different metamodeling verification activity from early specification through
environments, most widely used are the Meta Object design to development. On top of that it has to be in-
Facility (MOF) [10] from OMG and the Eclipse line with rigid certification requirements (e.g., DO-
Modeling Framework (EMF) [11] (a subset of MOF). 178B) imposed by authorities like FAA or EASA.
Model transformations (MT) are the backbone The PIM-PSM mapping process [17] needs to
of the MDD concept. Primarily, model support both automatic and user-driven design steps
transformations are responsible for the PIM-to-PSM as many critical design decisions are taken during the
transformations. However, MTs can also define views mapping process and cannot be fully automated.
on models and synchronization between different Furthermore, these decisions need to be recorded for
models (like UML class diagrams and relational traceability related certification requirements.
database schemas). Moreover, engineering models
are frequently mapped into mathematical domains by PSM needs to support the different viewpoints
model transformations to carry out model analysis as of the system [17] with a systematic separation of
early model based verification. Well-known system level aspects (e.g., functionality,
approaches for high-level declarative specification of dependability, security) and a strong separation
model transformations are the ATLAS Transformation between architectural and behavioral aspects. This
Language (ATL) [12], the VIATRA2 (VIsual allows to use appropriate COTS or proprietary tools
Automated model TRAnsformations) system [13] for the generation of textual artifacts.
and the GReAT (Graph Rewrite And Finally, PSM needs to support synthesis not
Transformation) framework [14]. only for source code but also system configuration,
certification and documentation artifacts.

Figure 1: MDD for Safety Critical System Development

 • The Platform Description (model)
Modeling Architecture of the DIANA describes the resource building blocks,
approach which are available to build a system. This
mainly includes ARINC 653 based
Within the DIANA project one of the main goals elements such as modules, partitions,
was to create an MDD based tool chain for the communication channels, etc.
analysis and generation of ARINC 653 real-time
operating system (RTOS) configuration files from • In the context of the DIANA project we
high-level specifications captured as platform supported MATLAB Simulink as a source
independent models. However, transforming these COTS language.
high-level models into ARINC 653 RTOS-specific
configuration artifacts is a complex task, which needs
to bridge a large abstraction gap by integrating
various tools. Moreover, critical design decisions are
also made during this mapping process. For this
reason, we used intermediate domain specific models
to subdivide the process into well-defined steps. The
overview of the model architecture is depicted in
Figure 2

Platform Independent Models:

In our approach the aim of the high-level
Platform Independent Model (PIM) is to capture the
high-level architectural view of the system along with
the definition of the underlying implementation
platform, while the Platform Specific Model (PSM)
focuses on the communication details and service
descriptions. All our models are defined as separate
EMF models.
In order to support already existing modeling
tools and languages (e.g., Matlab Simulink model,
SysML, etc.) we use a common architecture
description language called Platform Independent
Architecture Description Language (PIADL) for the
description of architectural details by extracting
relevant information from common off-the-shelf Figure 2: Modeling Architecture of the DIANA
modeling tools. As for capturing the underlying approach
platform (in our case ARINC 653) we use a Platform
Description model (PD) capable of describing
common resource elements. Functional requirements Platform Specific Models
are also incorporated into the PIADL along with the PSMs are encapsulated in the so-called
Platform Description. Integrated System Model that contains all relevant
low-level details of the modeled system. Essentially,
• PIADL aims to provide a platform
it is based on ARINC 653 and consists of the
independent architectural-level description
following sub-documents:
of event-based and time-triggered
embedded systems using message • The Interface Control Document (ICD) is
communication between applications. used to describe data structures and low-
 level data representation of systems and simulator SIMA running on Linux [18]. The
interfaces to ease integration of the following sections introduce these platforms briefly
described element with other parts of the and describe peculiarities of their configuration tool
system. It supports both high-level chains.
(logical) and low-level (physical)
Wind River VxWorks 653 RTOS
descriptions and was designed to be
VxWorks 653 is Wind River’s platform for
compatible with the ARINC 653 and
safety-critical applications certifiable according to
ARINC 825 data and application interface
DO-178B [19]. It is an IMA operating system with
descriptions. Its descriptors are simple
proven compliance to ARINC 653 [20][21].
XML files containing the serialized form
of the model describing the defined data VxWorks 653 implements IMA by means of
structures. virtualization technology [6]. There is a hypervisor
• The ARINC 653 System Architecture monitoring and controling a set of guests. Each guest
model describes the relations among all uses its own local executive, the Partition Operating
elements related to the system. More System (POS). Several types of POS are supported
precisely the model focuses on the (i) by the platform, such as the ARINC 653 APEX, the
details of the communication channels classic VxWorks RTOS or a general purpose OS like
between applications, partitions and Linux. Note that there is only one code instance per
modules, and (iii) the detailed allocation of POS physically present in the system that is linked to
the applications to partitions. the virtual address space of the partitions that actually
use this particular POS.
In order to support traceability, a trace element
is saved in the Trace documents for all model The hypervisor is called the Module Operating
elements of the PSM created during the mapping System (MOS). It implements time- and space
process. Such an element saves all PIM model partitioning, the ARINC 653 inter-partition
segments that were used for the creation of a PSM communication channels and the Health-Monitoring
model element. system. The MOS is the only component that runs in
privileged mode. Guest systems run in user space and
are not allowed to execute privileged instructions that
Target Platforms may impact the proper function of the system.
During the DIANA project, two OS target
platforms were used: Wind River’s VxWorks 653 Figure 3 (based on [6]) illustrates the
real-time operating system and GMV’s ARINC 653 architecture:

Figure 3: VxWorks 653 Architecture

 Note that the components of the system are not optimised for the Native POSIX Thread Library
linked together to one image; instead individual (NPTL), available on Linux since kernel version 2.6.
binaries are created for the MOS, for the POSes and
In SIMA, ARINC 653 partitions are mapped to
for the applications. The boot loader is responsible to
POSIX processes, and ARINC 653 processes are
locate the different components on the boot medium
mapped to POSIX threads. Each SIMA application is,
and to load them into memory according to a
hence, linked to a single POSIX program, containing
configuration derived from system configurations.
user code and data, the APEX code and data and,
The configuration the system integrator has to finally, the platform execution environment, i.e. the
provide in order to link, load and execute the system NPTL for Linux.
follows the VxWorks component structure [22].
The Module Operating System (MOS),
There is a configuration file for the MOS that defines
controlling the different POSIX processes, belonging
fundamental architecture-related settings, such as
to the same simulated module, is likewise linked to
processor frequency, page size and virtual and
one POSIX process. The following picture illustrates
physical memory; there are configuration files for the
this design:
POSes, defining their memory layout and how they
are loaded into memory; there are configuration files
for the applications, defining memory sizes and ports;
there are Health Monitor tables that define the health
monitoring on partition and module level; there is,
finally, a configuration for the module bringing the
single configuration files together and adding time
partitioning-related information.
This configuration is different from the
configuration defined by supplement 2 of ARINC
653. However, the next supplement will present a
new approach: The standard will define a set of data Figure 4: SIMA Architecture
types that must be used for an ARINC 653-compliant
configuration, but will not impose a schema that The APEX services are implemented by a static
describes how the elements must be related. The library, called POS. The POS implements the APEX
schema is left to implementations. process scheduler on top of the POSIX FIFO
scheduler (sched_fifo). POSIX features are
This approach of the ARINC 653 subcommittee encapsulated within a portability layer; this way main
is just a consequence of the fact that today’s parts of the APEX code do not rely directly on
operating systems do not comply with the standard POSIX, but on scheduling policies implemented by
schema. Configuration is tightly coupled with the OS the POS itself. The advantage of this approach is
architecture and, as such, is difficult to standardize. enhanced portability - there is even an
For the task of generating vendor-independent valid implementation of the SIMA POS, running on bare
configurations, this is probably not good news. Tools hardware - and the fact that scheduler features that
are needed that deal with the heterogeneity of introduce subtle differences between different POSIX
configurations. implementations are handled in the portability layer
GMV SIMA simulator and hidden from the APEX implementation.
Simulated Integrated Modular Avionics (SIMA) The MOS implements the APEX partition
is an execution environment, providing the ARINC scheduler. To be able to suspend and resume
653 Application Programming Interface (API) and partitions, commands are exchanged with the POS in
robust partitioning to operating systems that do not the partitions using signals and shared memory
support these features by themselves [7]. SIMA is segments. Obviously, this approach does not answer
designed to run on all POSIX-compliant OSes and safety and security threats, caused by random errors
in the partitioned code. The POS has to respond
correctly to given commands which may not be true way. The air conditioning pack is regulated by the
in the case where faulty or malicious application code pack controller to supply the mixing unit with a
corrupts the state of the POS. In fact, the MOS does sufficient flow of cool fresh air. This air is supplied
only simulate the behaviour of an ARINC 653 to arbitrary number of zones (in Figure 5 we depicted
compliant OS on top of non-safety aware systems two zones Aft. and Forward). In order to regulate the
like standard Linux. temperature of this airflow, the zone controller
regulates the amount of hot air added to the flow of
Since SIMA main purpose is simulation, it aims
cool air, which is set on the air conditioning panel
at full conformity with the standard. The SIMA
and monitored on the system display. Additionally, as
configuration is therefore strictly compliant to the
air-conditioning is a critical task all systems have a
schema defined in today’s ARINC 653 part 1 and 2.
redundant equivalent for better reliability.
Additional information that is needed by the system
is added by means of a separate configuration file. An overview of the air conditioning system is
This file defines the mapping of certain elements of depicted in Figure 5. Throughout the paper we will
the ARINC 653 configuration to the Linux OS; use this case study as our running example. It is a
APEX ports, for instance, can be mapped to UDP simplified version of the NLR demonstrator in the
ports. DIANA project.

Case Study: Air Conditioning Steps of the PIM-PSM Mapping

In order to introduce our approach, let us assume Process
a generic air conditioning system installed on an In order to introduce our PIM-PSM mapping
airplane. concept we first, highlight the steps of a general PIM-
PSM mapping process, then go into details about our
concrete implementation.

A general PIM-PSM Mapping Process for

Safety Critical Systems
A general PIM-PSM mapping process, in the
safety-critical system design domain, consist at least
the following steps (see in Figure 6 ):
1. Define / Derive the platform-independent
system model (PIM). The architecture-level
integrated system design starts by specifying a set of
applications attributed with properties extracted from
the system requirements (functional and non-
functional) and high-level initial system models
captured in SysML [2], AADL [3], etc.. These
properties are captured in the PIM model.
2. Define / Derive the Platform Description
Model (PD). The PD model describes all the details
(CPU, latency, bandwidth, etc) of the underlying
hardware platform including cabinet specification
and hardware resource descriptions
Figure 5: Overview of the Air Conditioning Case 3. Define / Derive Platform Interface (PI). This
Study model describes the high-level middleware services
Its task is to regulate the temperature and offered by the underlying platform.
pressure in the aircraft. This is done in the following
 4. Extract design constraints (performance, automated to obtain the PSM model. A valid PIM-
dependability, security, etc.). The PIM and PD PSM mapping should fulfill all design constraints
models should also include design constraints, (e.g. should not exceed HW limits like available
which have to be satisfied by valid PSM models memory).
derived as a result of a PIM-PSM mapping. These
7. Scheduling and Optimization. In addition,
constraints are extracted from the functional and non-
further scheduling and optimization steps can be
functional System requirements (e.g., modular
carried out after resource allocation, which is out of
redundancy).
scope for the current paper. For further reference see
in FRESCOR [23]
8. Evaluate the quality of the mapping. The
quality of the mapping can be evaluated against all
functional and non-functional requirements, and
certification means.

The DIANA Approach

We support the system architect by subdividing
the PIM-PSM mapping process into well-defined
design steps and by the precise definition of the
interactions and interfaces at each step. Individual
design steps are then organized into a complex
workflow [24], which is closely aligned with the
designated development process followed by the
system builder (system integrator, function provider
and platform provider.). In order to assist the system
architect, our framework guarantees that a certain
design step can only be started if all prerequisite steps
are successfully completed. Our framework is easily
customizable to incorporate additional design steps, if
required.
The high level workflow of the PIM-PSM
mapping process as used in the DIANA project is
depicted in Figure 7. The process consists of 22 steps
organized into five groups.

Figure 6: A Generic Mapping Process To illustrate some technicalities of our approach

we use the simplified Simulink model (depicted in
5. Define variability points / design choices. As Figure 8) as the starting PIM model of the air
there is more than one possible mapping of a PIM to conditioning case study.
a target PSM, the PIM-PSM mapping should offer
variability points to explicitly capture design Application Group
choices. These variability points can be subject to The group consists of steps to define the
future optimization steps. resource requirements of the applications and
partitions used in a module and create a viable
6. Resource allocation. As the core phase, the mapping that is compatible with the available
system architect assigns application types to resources and dependability requirements.
resources (called resource allocation), which
provide general rules / guidelines for the PIM-PSM
mapping. From these high-level guidelines, the actual
mapping instances (i.e. mapping of application
instances to actual resources) could be partially
Figure 7: Workflow of the DIANA PIM-PSM mapping process
 First, the PIADL and the PD models are For easier readability (i) attribute types are
imported into the framework. This step also resolves excluded from the figure and (ii) references and
certain dependability attributes defined in the PIADL association are depicted by simple lines.
like redundancy degree of applications and messages
As the final step in the group, all allocations of
(e.g., triple or double modular redundancy etc.).
applications-to-partitions conform to the defined
As the platform description does not include all constraints and requirements are computed. This way
information needed for the allocation process and the system architect can select a valid allocation and
configuration generation, the system architect needs (if required) can take into account additional non-
to (i) define the memory requirements and functional requirements.
compatibility mapping of the applications and (ii)
new partitions or modify existing ones and define
their memory requirements.

Figure 9: Partition Creation

The allocation problem is solved as a constraint
satisfaction problem.
Communication Group
The group involves steps in the PIM-PSM
Mapping editor that carry out the allocation of inter-
partition communication channels and the
specification of ports residing on each end of these
Figure 8: PIM model of the Air Conditioning Case channels.
Study1
The allocation is based on the architecture
To demonstrate how these steps are captured on defined in the PIADL model (derived from a
model level, Figure 9 illustrates the low level model Simulink model), the selected application to partition
elements created for a partition (partitions creation mapping and the redundancy requirements of the
step). Model Elements in yellow and dashed lines are applications. Based on this information the allocation
newly created, while elements in green (and solid algorithm creates the required ARINC 653 ports and
references) are already existing in the model. The connects them.
tags <<Integration>> and <<PD>> represent the
package of the model element. Partitions are Additionally, the system architect needs to
defined/stored in the Platform Description model define the ARINC 653 specific parts like the queue
with separate model elements describing their length and the VxWorks specific queuing protocol to
corresponding memory requirements capturing the be able to generate the configuration files.
size, access (type) and type attributes. PSMRoot is Figure 10 depicts a simple example how the
the root element of the integration model and it holds allocated channels are visualised. In this case Data
references between the elements of the PIADL, PD Monitoring application allocated over the I/O
and the PSM models. Processing partitions uses the Temp. channel to send
the temperature value to the Refresh GUI application.
1
© 2010 NLR
 Figure 11: Definition of the Temp value in ICD
Artifact Generation Group
Figure 10: Allocated Communication Channels Finally, when the prerequisite steps for a certain
code generator is finished the actual textual
representation is synthesized by separate dedicated
Health Monitoring Group code generators.
The group consists of steps to define the Health
Monitoring tables for module, partition and In our case the ICD generator simple serializes
application level along with the different error the model into its XML representation using the built
entities and actions to be carried out. in support of the Eclipse Modeling Framework. As
for the other artifacts we hand-coded the generators
All these definitions are done by the system in java to derive the required formats defined by the
architect by hand. The framework gives support for two platforms.
early validation (e.g., naming conventions, required
action definitions etc.) based on the specification of The communication architecture, depicted in
the different tables and the system-specific Figure 8, is mapped to ARINC 653 ports through the
requirements for health monitoring tables.. defined mapping process and then automatically
generated both the ARINC 653 and the VxWorks 653
The defined tables are saved in the Platform specific module and ApplicationDescription XML
Description model with the appropriate references configuration tables. A fragment of the generated
from the PSMRoot of the Integration model. configuration tables capturing the communication
ICD Group channel depicted in Figure 10 is captured in Figure
In this group steps related to the description of 12.
interfaces and messages provided and required by
applications. These are user driven mapping steps,
where PIM types and messages, are refined with
platform specific information like encoding, default
value, etc.
Figure 11 describes how the Temp PIM type is
refined into the Int1_100 PSM representing an
integer value with a domain of 1-100. The Int1_100
type is based on the predefined 16 bit unsigned
integer type from the ICD with additional constraints
over its domain. Based on these PSM types, complex
messages are defined following a similar way, where Figure 12: Example ARINC 653 Module and
the ICD provides the basic structures like arrays, VxWorks Application Description configuration
buffer, etc.
Traceability Contracts
Additionally, as an essential requirement of DO- During a development process certain steps
178B certification, continuous traceability has been require external COTS tools (e.g., Matlab, SAL, etc.)
carried out from the high-level requirements to the or user interaction to perform their task. In order to
deployed applications (depicted in Figure 13). guarantee that the result of these steps is acceptable
and the process can continue, the definition of
contracts [26] is a well-known paradigm.
The idea is to guard both the input and output of
a step by specific constraints. Thus, a contract is
composed of a precondition and a postcondition. In
our interpretation a precondition defines constraints
that need to be fulfilled by the input of the step in
order to allow its execution, while the postcondition
guarantees that the process can continue only if its
constraints are satisfied by the output.
In our approach we used graph patterns (GP)
[27] to capture such contracts. GPs are frequently
considered as the atomic units of model
transformations. They represent conditions (or
constraints) that have to be satisfied by a part of the
Figure 13: Traceability between models and underlying model. Based on these contracts we
configuration artifacts investigated two promising approaches to support
In case of the design phase we used (i) inter- early validation and verification.
model traceability based on the Integration Model On-The-Fly Evaluation of Contracts
that keeps track of all manipulations done during the One of the main advantage using contracts to
PIM-PSM mapping process and (ii) model-to- specify constraints on the input and output (model) of
configuration traceability with XMI files connecting each step in the development process is that it allows
generated configuration elements to their fine grain (step level) validation of model changes
corresponding model entities. This allowed end-to- throughout the whole workflow. However, graph
end traceability from the PIADL model to the patterns can express complex model constraints
generated configuration tables. It is important to containing cycles, attribute conditions, transitive
mention that the current implementation requires an closures and recursive calls. Additionally, as these
explicit definition of traceability elements between queries are executed rather frequently in interactive
the various models. However, currently we are modeling applications, they have a significant impact
investigating special live model transformations [25] on the runtime performance of the tool, and also on
to give support for automatic generation of the end user experience.
traceability elements without explicit definition.
In our framework to provide on-the-fly
evaluation of constraints, we applied EMF-IncQuery,
Verification and Validation Support a state-of-the-art pattern matcher engine over EMF
Keeping the design and verification aspects models based on incrementally maintained caches,
tightly synchronized, enables early validation as close resulting in (almost) instantaneous contract
as possible to the corresponding model/code evaluation. More details are available in [28].
development time, thus providing better feedback and Without going into details the simplified
error detection. To support early validation of example contract depicted in Figure 14 captures the
modeling artifacts during our development process condition that, “if there exist an Application with an
we used contracts to guard each steps. ApplicationInstance (as the precondition), then after
the allocation step there cannot be
ApplicationInstances that are not allocated to a
Partition (as the postcondition)”. For more details with significant relevance to design and verification
see [24]. of embedded systems involving model based
techniques.
INDEXSY [15] aims to realize industrial
implementations of cross-domain architectural
concepts [17] developed in the GENESYS [29]
project and give tool support based on MDD for its
three target domains: automotive, aerospace and
railway.
COCONUT [30] focuses on the definition of a
formal framework [31] based on a tight integration of
Figure 14: Contract for Application Allocation design and verification through refinement steps of
an embedded platform design flow, from
Validation of end-to-end traceability specifications to logic synthesis and software
One key question in end-to-end traceability is to compilation.
demonstrate that any target element can be traced
back to its corresponding requirement. Showing this TopCased [32] is an open source tool-kit (over
ability in a model driven development process can be the Eclipse platform) for the design, development and
problematic as separate part of models can be parts of deployment of safety critical system using novel
the traceability (e.g., in our case the integration MDD techniques and support for languages like
model is also part of the traceability) resulting in AADL and SysML.
complex trace paths. CHESS [33] seeks to improve Model Driven
To solve this issue, our idea is to validate the Development practices and technologies to (i) better
existence of such trace paths through contracts and address safety, reliability and robustness
show that complete traceability is present in the functionalities as required by the aeronautical and
whole mapping process from the PIADL down to the railway industry and (ii) develop techniques to
generated artifacts. The idea is based on the guarantee the correctness of assembled component
following assumptions: (i) defining the traceability embedded systems by reusing certification artifacts
relation, as a contract, between the input and output of the components used for the complete system.
of a step is relatively simple, (ii) if a step is FRESCOR [23] aimed to integrate advanced
completed in the process and its contracts are flexible scheduling techniques directly into an
validated then their postconditions can be treated as embedded systems design methodology, covering all
valid statements over the model, and finally, (iii) the levels involved in the implementation, from the
using the defined workflow of the development OS primitives, through the middleware, up to the
process all steps required for the generation of a application level using contracts to define the
configuration element can be followed back to its application requirements.
starting point (e.g., import step, creation step, etc.)
allowing an induction based reasoning over the CHARTER [34] focuses on cost-reduction of
contracts of the traversed steps to show the existence certification of critical embedded systems by
of a valid traceability path.. However, it only proves integrating real-time Java, model-driven
the existence and does not provide the traceability development, rule-based compilation, and formal
matrix; future work is required to automatically verification into a novel development process called
generate it. Quality-Embedded Development (QED).

Related Work Conclusion and Future Work

There are numerous approaches in the literature Our approach demonstrated that Model-Driven
introducing various model based techniques for the Engineering can be effectively applied for the
development of embedded system. Here we give a systematic development of ARINC 653 configuration
brief summary of some current EU research projects tables. Additionally, we demonstrated the use of
model based validation techniques such as (i) http://www.omg.org/mda/mda_files/LockheedMartin.
complete end-to-end traceability from the high-level pdf.
models down to the generated artifacts and (ii) model
[5] RTCA/EUROCAE, 1992, Software
based on-the-fly validation of design contracts during
Considerations in Airborne Systems and Equipment
the development process.
Certification.
However, during the evaluation of the proposed
[6] Wind River, 2007, VxWorks 653 for Integrated
technologies we have encountered gaps and
Modular Avionics, Wind River White Paper,
shortcoming that point to future work and new
Alameda.
research directions:
[7] GMV, 2009, SIMA Overview, GMV White
One key issue for the success of MDE in the
Paper, Lisbon.
safety-critical domain is the certification of model
transformation. MT serves as the backbone of almost [8] The DIANA Project, Distributed, equipment
all model based technologies from code and model Independent environment for Advanced avioNic
synthesis through model validation techniques to Application, http://dianaproject.com.
simulation. Up to date many work has been done [9] AUTOSAR Consortium: The AUTOSAR
regarding the V&V of transformations [35], however, Standard, http://www.autosar.org/.
certification issues were rarely covered in recent
publications. Additionally, the complexity of tools [10] The Object Management Group, Meta Object
may impose high qualification costs on tool vendors Facility (MOF) core specification version 2.0
http://www.omg.org/docs/formal/06-01-01.pdf.
As development of safety-critical system usually
requires large number of developers the need for [11] Eclipse Foundation, Eclipse Modeling
advanced collaborative support for the definition Framework: http://www.eclipse.org/emf.
models like versioning, distributed development, [12] ATLAS Transformation Language,
access control etc. is becoming a key question http://www.eclipse.org/atl/.
[36][35].
[13] VIATRA2:-VIsual Automated model
Finally, MDE promises an easier way of TRAnsformations, http://wiki.eclipse.org/VIATRA2.
integrating various tools based on a common
integrated model (or model bus [32]) that allows their [14] GReAT: Graph Rewrite And Transformation
input and output models of the various tools to be http://www.escherinstitute.org/Plone/tools/suites/mic/
treated in a common way. Additionally, it can give great.
support for model based traceability a common [15] The INDEXYS Project, INDustrial EXploitation
requirement by various certification authorities. of the genesYS cross-domain. architecture,
http://www.indexys.eu/.
References [16] Miller, P. Steven., 2009, Bridging the Gap
[1] Airlines electronic engineering committee Between Model-Based Development and Model
(AEEC), 2006, avionics application software Checking, 2009, In Proc. of 15th International
standard interface - ARINC specification 653 - part 1 Conference on Tools and Algorithms for the
(supplement 2 - required services), ARINC Inc. Construction and Analysis of Systems, York, UK,
Springer, pp 443-453.
[2] The Object Management Group: System
Modeling language, http://www.sysml.org/. [17] Obermaisser, R., H. Kopetz (Eds.), 2009,
GENESYS: A Candidate for an ARTEMIS Cross-
[3] International Society for Automotive Engineers, Domain Reference Architecture for Embedded
Architecture Analysis and Design Language, Systems; Germany, SVH
http://www.aadl.info.
[18] Schoofs, T:, 2010, The Use of SIMA in the
[4] Clarck, L., T. Ruthruff, B.. Hogan, , Development DIANA Project. A Success Story, GMV White
of Lockheed Martin's, F16 Modular Mission Paper, Lisbon.
Computer Application Software using MDA
[19] Parkinson, Paul, Larry Kinnan, 2006, Safety Computer Aided Verification (CAV), Edinburgh,
Critical Software Development for Integrated Scotland, Springer, pp 425-429.
Modular Avionics. Wind River White Paper,
[32] TopCased, The Open Source Toolkit for Critical
Alameda.
Systems, http://www.topcased.org/.
[20] Felipe, Sérgio, 2007, ARINC 653 Validation
[33] The CHESS project, Composition with
Test-Suite Execution on VxWorks 653 2.1, Report
Guarantees for High-Integrity Embedded Software
Skysoft Portugal and Wind River, Lisbon.
Components Assembly, http://chess-
[21] Schoofs, Tobias, 2009, ARINC 653 Validation project.ning.com/.
Test-Suite Execution on VxWorks 653 2.2, Report
[34] The CHARTER project, Critical and High
GMV and Wind River, Lisbon.
Assurance Requirements Transformed through
[22] Wind River, 2007, Platform for Safety Critical Engineering Rigour, http://charterproject.ning.com.
ARINC 653 - Configuration Reference 2.2, Wind
[35] Varró, Dániel, 2010, Towards Certifiable Model
River Manual, Alameda.
Transformations: A Survey, Budapest University of
[23] The FRESCOR project, Framework for Real- Technology and Economics, Department of
time Embedded Systems based on COntRacts, Measurement and Information Systems, Technical
http://www.frescor.org/. report, Budapest.
[24] Balogh, A., et al, 2010, Workflow-Driven Tool [36] Bendix, L., Par E., 2009, Requirements for
Integration using Model Transformation, Graph Practical Model Merge, In Proceeding of the 12th
Transformations and Model-Driven Engineering, International Conference on Model Driven
LNCS 5765, Springer. Engineering Languages and System, Denver, USA,
Springer, pp. 167-180.
[25] Ráth, I., A. Ökrös, D. Varró, 2010,
Synchronization of abstract and concrete syntax in
domain-specific modeling languages, Software and Acknowledgements
System Modeling, Spec. Issue on Traceability,
We would like to thank to Klaas Wiegmink,
Springer.
from NLR, for his help with air conditioning case
[26] Meyer, Bertrand, 1992, Applying ”design by study and Olivier Charrier, from WindRiver for his
contract”, Computer, IEEE, 25(10), pp. 40–51. support on VxWorks.
[27] Varró, D., A. Balogh: The model transformation This work was mainly supported by the EC FP6
language of the VIATRA2 framework, 2007, Science DIANA (AERO1-030985) European project,
of Computer Programming 68(3), Elsevier, pp. 214– however, the validation of traceability by contracts
234. research direction was also partially supported by the
Hungarian CERTIMOT (ERC_HU_09) project and
[28] Bergmann, G., et al., 2010, ,Incremental Model
the Janos Bolyai Scholarship.
Queries over EMF Models, In Proceeding of the 13th
International Conference on Model Driven
Engineering Languages and System, Oslo, Norway, Email Addresses
Springer.
Ákos Horváth: [email protected]
[29] The GENESYS project, GENeric Embedded Dániel Varró: [email protected]
SYStem Platform, http://www.genesys-platform.eu/.
Tobias Schoofs: [email protected]
[30] The COCONUT project, A COrrect-by-
CONstrUcTion Workbench for Design and 29th Digital Avionics Systems Conference
Verification of Embedded Systems, October 3-7, 2010
http://www.coconut-project.eu.
[31] Bloem R., et al., 2010, RATSY - A new
Requirements Analysis Tool with Synthesis. Proc. of