A demonstrator for the verification of the selective
integration of the Flexible Platform approach into
Integrated Modular Avionics
Darbaz Nawzad Darwesh
Institute of Aircraft Systems
University of Stuttgart
Pfaffenwaldring 27, 70569
Stuttgart, Germany
darbaz.darwesh@ils.uni-stuttgart.de
Björn Annighöfer
Institute of Aircraft Systems
University of Stuttgart
Pfaffenwaldring 27, 70569
Stuttgart, Germany
bjoern.annighoefer@ils.uni-stuttgart.de
Abstract—This article introduces a demonstrator built to
prove the operability of the selective integration of the Flexible
Platform approach into Distributed Integrated Modular Avionics
(DIMA) architectures. Safety-critical system functions rely on a
complex system management, which covers fault detection,
redundancy management, and isolation of platform modules.
Commonly, the system management causes the majority of the
development and certification efforts. However, the IMA
approach standardizes only the management of the resources and
time of each hosted system function on the underlying hardware.
Additionally, relevant system management functions - such as
redundancy management for the safety-critical applications - is
developed and implemented individually in the system function
itself. The Flexible Platform, developed by the Institute of
Aircraft Systems (ILS) at the University of Stuttgart, provides
system management mechanisms as a generic software. The
approach, presented in this paper, intends to use the Flexible
Platform on IMA selectively for safety-critical system functions
besides state-of-the-art ARINC653 applications. For the
verification of this new approach, a lab demonstrator with
industrial IMA modules is established to run predefined
demonstration scenarios that validate the key-characteristics of
the selectively used Flexible Platform on DIMA architecture.
Keywords—DIMA, IMA, ARINC653, system management,
Flexible Platform, lab demonstrator, high-lift system, platformbased development, Selective Middleware approach
I.
INTRODUCTION
New aircraft system designs implicate a high number of
system functions, which require a new system architecture in
order to keep the avionics low in context of hardware size,
weight and power (SWaP). A solution to these is the IMA
concept for commercial aircraft (CS-25). The Integrated
Modular Avionics concept replaces numerous federated
controllers and line replaceable units (LRUs) with fewer, more
centralized processing units [4]. This approach is based on
standardized modular hardware, real-time operating systems
(RTOS), and an API 1 , which separates applications and the
underlying platform. The segregation of the partitions is
realized in temporal and spatial partitioning. Hence, a single
IMA platform hosts multiple aircraft systems with different
design assurance levels (DAL) [1]. Another aspect deriving
from efforts to reduce aircraft weight is the use of standard
ARINC664P7 network [2] realized through Avionics Full
Duplex Switched Ethernet (AFDX). It creates a reliable
network covering both the aircraft-level (communication
between LRUs, IMA centers, and other smart peripherals) and
the system domain level (communication between modules
within a particular group of systems) [4]. In the second IMA
generation, also called distributed IMA (DIMA), as shown in
Fig. 1, Remote Data Concentrators (RDC) were introduced for
the Airbus 350 [7]. RDC are placed close to peripherals and
remotely distributed over the airframe. They concentrate and
convert data from conventional interfaces (ARINC429,
Discrete, Analogue, LVDT etc.) to AFDX. RDC separate the
Input/Output (I/O) capabilities from the computing modules,
which is realized for instance in Core Processing Input Output
Modules (CPIOM) that are used in A380. This separation
facilitates in future to build Core Processing Modules (CPM)
that are allocated in the avionic bay provide solely computing
power and AFDX interfaces.
The resulting benefit is the reduction of cable length and its
associated weight, which decreases the SWaP 2 factor. After
the first implementation of IMA in the A380 and Boeing
787/777, developers recognized the elaborate and complex
configuration for hosted system functions [8, 9]. Automation
and optimization tools are developed and researched to
minimize the complexity in integration, testing, certification,
design optimization etc. for IMA resp. DIMA approach [10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22]. In addition,
several presented DIMA based demonstrators are built for
verification and validation of new platform approaches such as
published in [6, 13, 23, 24].
2
1
Application Programming Interface standardized from
ARINC653 for the IMA approach [1].
Reinhard Reichel
Institute of Aircraft Systems
University of Stuttgart
Pfaffenwaldring 27, 70569
Stuttgart, Germany
reinhard.reichel@ils.uni-stuttgart.de
Size, Weight and Power (SWaP) must be managed and
reduced across all aircraft systems in order to improve
operational efficiency and logistics, weight and total cost of
system ownership.
development of a demonstrator that can demonstrate the
Selective Middleware approach.
Fig. 1. Architecture of a Distributed Integrated Modular
Avionics (DIMA) system
In all current IMA research, however, the complexity of faulttolerated system functions remains in the development of
application software. The IMA-platform itself provides
RTOS-specific management units - such as partition, process,
time, partition communication management and health [1, 25,
26], but safety-critical system function (e.g. according DAL
A 3 ) requires redundant system peripherals (sensor, actuator,
etc.) and partitions. Redundancy implies a complex
management for the application software [46]. IMA does not
provide any abstraction layers for such kind of tasks.
Specifically for highly redundant system functions, this
represents a major part of the application with respect to
complexity. The system management significantly increases
the development, testing and certification effort, even if the
basic system function is just a simple one. This is the
motivation for the approach of an advanced integrated
avionics architecture, the so-called “Flexible Platform” at the
Institute of Aircraft Systems (ILS) at the University of
Stuttgart [28, 29, 31, 32, 33, 34, 35, 36, 37].
The Flexible Platform (FP) provides standardized system
management mechanisms as generic software as depicted in
the Fig. 2. An additional abstraction layer (PLAMA) operates
between the RTOS and the hosted applications. It organizes
the partitions signal and network communication as well as
the complete redundancy management to operate the system in
a fault-tolerant way.
A knowledge-based tool suite - so-called ILS Toolsuite automatically derives the instance of the FP [30]. With model
transformations, most artifacts of the system development
process are generated including test cases and certification
documents [38, 39]. However, the current FP requires the full
resource control over hardware and the operating system. It is
desired to merge the capabilities of the FP to IMA and DIMA
architectures with a selective use of the Flexible Platform
called Selective Middleware (SMW). This research is carried
out on existing state-of-the art DIMA hardware and software
and focusses on extending seamless integration. The scope in
this paper is the definition of demonstration scenarios and the
3
The probability of failure by DAL A (Catastrophic) is
defined to be less than 10-9 per flight hour. Safety-critical
software is developed by using DO 178 B/C guideline.
Fig. 2. An integrated avionics architecture based on the
Flexible Platform approach of the ILS
The remainder of this article is organized as follows. In
chapter II, the background of the Selective Middleware
approach is presented. In chapter III, the demonstration scope
and demonstrator design is derived with all relevant
components and in chapter IV, detailed demonstration
scenarios are defined. The article concludes a conclusion and
an outlook in chapter V.
II.
A SELECTIVE USE OF THE FLEXIBLE PLATFORM WITH
DIMA
This chapter introduces the Selective Middleware approach
within the context of the Flexible Platform. The middleware
(MW) reuses most functions of PLAMA as well as the modeldriven auto-generation.
A. New platform design within MW and DIMA approach
To benefit from the advantages of the Flexible Platform on
DIMA, parts of it need to be adapted to fit the IMA
development process. With the integration of the middleware,
the function supplier (FS 4) can focus on a simplex-minded5
control function (law), while the MW carries out the system
management. The system management and its complexity,
distribution, fault-tolerant, and redundancy are transparent to
the hosted law [30].
The function supplier can voluntarily use the MW as
underlying part of the application partition of a selected
system functions as depicted in Fig. 3.
The combination of the DIMA architecture (Fig. 1) and the FP
architecture (Fig. 2) conduct to the system design depicted in
Fig. 3. However, the realization of the MW-compatible system
architecture requires appropriate hardware modules.
4
Function Supplier or Application Supplier is defined as IMA
actor in DO-297 [3]. He is responsible for the system
application development and its qualification.
5
Simplex-minded denotes that the system function is reduced
to the bare control algorithm. Peripheral, lane and operation
management are not contained in the simplex-minded law.
Fig. 3. DIMA architecture with Selective Middleware approach
There are three different module types defined:
- The Remote Data Concentrator (RDC) used as single
lane I/O module, provides a variety of physical I/O
interfaces to connect peripherals. The RDC-RTOS
are not ARINC653P4-compatible RTOS. RDC act as
a gateway where signals from peripherals are
converted for transmission via the AFDX network.
They are located near to sensors or other devices. In
addition, logical operation rules can be configured to
provide independent control functions.
- The Core Processing Module (CPM) is the main
computing unit in a distributed avionics architecture
providing an ARINC653 compatible RTOS. Due to
the redundancy mechanisms of the FP, it must offer
two similar, synchronized lanes. It is generally only
connects to the AFDX network for data transfer.
- The I/O Module Duplex (IOMD) is a special similar
dual lane module: It consists of I/O interfaces and an
ARINC653 RTOS. It is capable to perform fast
closed-loop control and in doing so, it supports high
integrity driving and monitoring of nearby actuators.
CPM and IOMD are the only modules, which can include the
MW components. Unlike the in FP, all peripheral data (sensor
values, etc.) must be processed on CPM or IOMD and not in
RDC.
B. The selectively used middleware
The selectively used MW provides a platform management
(PLAMA) and an additional abstraction layer: the Service
Provisioning Layer (SPL). PLAMA comprises of platform
communication (PLACOM) and platform supervisor
(PLASMA). PLACOM processes all intra- and inter-module
communication. In addition, it treats signal unification and
consolidation of Quality-of-Service (QoS) information for
redundant signals. The QoS indicates the signal integrity.
PLASMA evaluates all QoS information and decides whether
platform resources are valid for the current condition [40].
The ARINC653P4 RTOS and the module drivers are already
present in DIMA modules through the module supplier and
therefore are not in the scope of the MW, since the SPL
facilitates ARINC653P4 compatibility of MW and ensures a
wide range of commercial RTOS. As an addition, the SPL
provides the ARINC653P4 API to the law communication
making itself transparent for the system application. The SPL
routes all API calls of the MW into both directions (law and
RTOS). It takes special care of limited computation time,
memory and interface resources. Detailed description of the
SPL and internal activities can be found in [41].
In context of high integrity requirements, AFDX is a challenge
to the MW by being asynchronous and lossy. In case of data
exchange between two similar dual lane modules for data
consolidation6, message payloads can be burdened with a high
latency that conducts to consolidation failures. Therefore, an
algorithm called “Q2 Algorithm” is established and integrated
into the middleware to guarantee a robust and fault-tolerant
communication via AFDX [42].
C. Integration of the Selective Middleware approach into
IMA development process
The MW is in the responsibility of the FS, because it is
integrated into a partition. Consequently, it has to be
compatible with the IMA development process as depicted in
Fig. 5. The system designer (SD) designs the system
architecture in the ILS TopLevel according to the system
requirements and ILS Toolsuite user´s guide [30]. The typical
IMA exchange file are so-called aircraft interface control
documents (A/C ICD 7) can be then generated automatically
from the ILS TopLevel model. The import process of the
preliminary I/O interfaces budget allocations to the ILS
TopLevel should be provided by automated transformations.
6
Correctness of data should be guaranteed for fault detection.
Aircraft (A/C) Interface control document (ICD) is the
common data exchange format in the IMA development
process [44].
7
Fig. 4. Demonstrator system architecture
Hence, delivered I/O interfaces budget allocations (input
AC_ICD format) from module integrator (MI) and function
specification incl. the AC_ICD from system designer
processed (left side on the Fig. 5) from ILS Toolsuite to
instantiate the ILS TopLevel model.
Fig. 5. ILS Toolsuite access to IMA development process
The required law shall be developed according the Function
Specification from SD by Function Supplier and it should be
suitable to the MW interface.
After the ILS TopLevel model is instantiated and all interfaces
for the law are defined, the complete module configuration
files are generated from the ILS Toolsuite. The Module
Integrator uses the generated module interface configuration
files to configure the IMA module interfaces via the IMAToolchain. In addition, generated MW within the law software
loads are loaded in the determined partition.
III.
THE DEMONSTRATION SCOPE
The presented demonstration scope is an IMA-base high-lift
system (HLS) depicted in Fig. 4. The demonstrated HLS is
limited to the flap functionality. The system architecture of the
HLS to be implemented is patented by Airbus [43]. Elmahdi
already evaluated an IMA-based HLS without the usage of
MW or other platform approaches [24]. His focus was to
evaluate the required time constraints for the monitoring and
control functions - such as flap asymmetry function. The HLS
is categorized as a safety-critical system function. In addition,
it should be shown that the legacy application executes
according to its specification.
The DIMA architecture of the demonstrator consists of two
CPM, two IOMD and four RDC. The modules are connected
via two asynchronous AFDX networks (red and blue) with
AFDX-Switches. All used peripherals are simulated for both
defined system functions (High-lift System and Legacy
application). Therefore, a test system is configured and
connected to the demonstrator. It emulates all peripheral
devices and redundant sensors or actuators
The HLS system, the IMA demonstration test rig and the test
system are described in detail the following sections.
A. The IMA hardware test rig
The used hardware is supplied from an industrial project
partner with all required tools (IMA-Toolchain) to configure
the hardware. Three different module types are used for the
demonstrator. The first type is the “common remote data
concentrator” (cRDC) module [45] which exactly fulfills the
RDC definition specified in II. It consists of numerous I/O
interfaces including AFDX end system and a core software
(cRDC OS). It is DAL-A-certified single lane hardware and
actually used in A350 XWB. A specific, certified toolchain is
provided to configure cRDC modules with AC_ICD files. The
second module type is a single lane module within the RDCHW functionality and it provides an ARINC653P4 compatible
RTOS. In the Flexible Platform specification, CPM are
specified as similar dual lane modules. Those similar dual lane
modules are not available in the industry yet. Therefore, two
single modules of the second type are combined
(synchronized) to one logical similar dual lane module and is
used as CPM. In our case both lanes are connected via two
CAN buses and the synchronization mechanism is
implemented on the MW (Application level). The third
module type is so-called remote controllable equipment (RCE)
and is used as IOMD [6, 45].
a distributed data base depicted in Fig. 7. Following
simulation boards are applied in the test system:




SYNCHRO8 and LVDT9 simulation board
Discrete boards
Ethernet board
AFDX simulation board (for SPY)
Fig. 7. Demonstrator with test system
Fig. 6. Demonstrator with industrial hardware
It is a similar dual lane prototype platform and supports high
integrity requirements. The RCE concept is based on the RDC
functional requirements but extends its capabilities by
covering the processing functional requirements as well [45].
An ARINC653P4 RTOS is implemented in the way that
applications requiring fast closed loop control and high
integrity are supported. The demonstrator is depicted in Fig. 6
with industrial modules. All modules of the demonstrator are
connected to the test system that complements the full
operability of the allocated system functions.
B. Test system for the demonstrator
The test system has two objectives: On one hand it shall
provide an environment which exactly reproduces the real
peripheral behavior and on the other hand it shall provide
features that facilitate the integration and verification of the
implemented system functions.
It is a standard PC running a real-time Linux operating
system. It runs the implemented simulation models of the
peripherals and data gained by the simulation boards linked to
The SPY tool provides the possibility for real-time debugging
of the hardware under test – the CPM and IOMD in this case.
There is no impact on the deterministic behavior of the
hardware under test or real-time monitoring and manipulation
of data for verification reasons.
The SPY consists of two software units, the SPY-Client and
the SPY-Server. The SPY-Client as part of the MW is
implemented on the test system and communicates via AFDX
with the SPY-Server.
The SPY-Client provides the SPY-Server with user commands
(logging or manipulating of data). A configured Verification
Integration Test Environment Graphical User Interface (VITEGUI) enables the user to interact with the SPY-Client. The
design architecture of SPY is depicted on Fig. 8.
C. System functions hosted on DIMA within selective MW
The simplified development of the traditional IMA
applications by the services of the MW and DIMA
functionalities is desired. To proof this approach a high-lift
8
SYNCHRO board simulates SYNCHRO sensors that is
typically used to feedback angular position of rotating valves.
9
Linear variable differential transformer (LVDT) board
simulates LVDT sensors that is used for measuring linear
displacement.
system (HLS) with the MW and a simple legacy application
that does not use the MW service were established.
-
transmitted to the installed motor through DSO
signals. At the same time, the position of the
transmission shaft is read by the FPPU. If the flap
surface reaches the target position or any failures
occurred, the transmission will be locked by the
POB. The FAS consists of two PCUs (left and right
side) and valve blocks where the shaft transmission
velocity is accumulated by the gearbox.
WTB Controller: This controller is responsible for
monitoring the position of the transmission shaft on
the wing tip through the APPU-Sensors. The WTB
Controller controls their WTBs (left and right side)
through DSO signals, which are similar to the PCU
Controller. In case of a system failure, the drive
sequence will be disconnected. This means that the
POB (controlled by PCU Controller) and both of the
WTBs on the left and right hand will be commanded
to release (brake). If the WTB releases, both WTBs
on the left and right hand are commanded to be
engaged.
Fig. 8. SPY design
1) HLS on DIMA within MW
The investigated HLS consist of a flaps lever that is based on a
Command Sensor Unit (CSU) and a flaps actuation system
(FAS) which includes all sensor and actuator units for flaps
such as Wing Tip Brakes (WTB), Asymmetry Position Pickoff Units (APPUs), Pressure Off Brake (POB) and Feedback
Position Pick-off Units (FPPU).
The CSU is a unit of multiple sensors reading the flaps lever
position and controllers converting this position into discrete
signals. There are two sensors on the left side and two on the
right side of the flaps lever. Each sensor reads five discrete
signals which define the bit-pattern of the actually adjusted
flap lever position.
The original HLS system function10 that includes all required
sub functions (Monitor, command and control function) is
separated into command law and control law. The command
law generates the target position command (TPC) for the
target flap position by interpreting the CSU signals and the
calibrated airspeed (CAS). The protection function and the
load relief function both are implemented in command law to
automatically retract or extend the flaps by increase resp.
decrease of the CAS. A button parameter (AUTOFCN_BTN)
is defined where it is required to eliminate the protection
functions.
The control law includes all control and monitoring functions
to drive the flaps actuation system consisting of Power
Control Unit (PCU) and WTB_LH /-_RH Controller. The
tasks of each the controller are described as below:
- PCU Controller: The main task of the PCU
Controller is to command the valve block that drives
the transmission shaft that connects to the gearbox on
FAS. The TPC (retracting/extending) signal is
10
The HLS system function developed by federated design
way is allocated on the slat flap control computers (SFCC).
The HLS is realized through two independent channels to
control the FAS because of the required high system
reliability 11 . The overview of the HLS function dataflow
without the allocation of the laws on the target HW modules is
depicted in Fig. 9.
Fig. 9. HLS components and signal flow
The reaction time of control law is distinguished from the
command law, because of the required short reaction time
constraints of the monitoring functions. Therefore, the control
law shall be implemented with a high sampling rate and close
to the FAS peripherals to reduce the latency.
The designed HLS within the defined laws shall be allocated
on the demonstrator architecture. According to the sample rate
and module interfaces, the command law is allocated on the
CPM and the control law on the IOMD.
11
E.g., Single failures of the items of equipment shall not lead
to catastrophic failure conditions.
The system architecture defines two CPM and two IOMD
related on the reliability and availability. To read the CSU
signals four cRDC are required to transmit all signals
independently from the flaps lever to the CPM via the AFDX
network. Two AFDX networks are inserted to fulfil the system
reliability requirement.
The HLS specific data of function specification and
preliminary I/O interfaces budget allocations from module
integrator and system designer is provided, which includes all
HLS resources and system design. This information can then
be used to model the ILS TopLevel model by using ILS
Toolsuite. The ILS TopLevel instantiated for the HLS
includes the system architecture (law allocation on the target
modules), all defined modules, all interfaces and network
definitions. Automatically generated configuration files within
the MW files from the ILS TopLevel model and the provided
HLS laws can be used to configure the modules.
B. Configuration
The ILS Toolsuite is established for the generation process of
configuration files. In this scenario, the utilization of the ILS
Toolsuite is presented to configure demonstrator modules. All
module-specific configuration files and loads are generated
automatically through the connected ILS Toolsuite and IMAToolchain by using the AC_ICD format. Each module resp.
module lane gets their own configuration files. The AC_ICDs
are used from IMA-Toolchain to generate ARINC665-loads
data to configure RDC and CPM. Additionally for CPM, there
are MW configuration binaries. Because IMA-Toolchain is
not used for IOMD in our case, all IOMD configuration files
and loads are generated from the ILS Toolsuite.
All configuration files have to be generated successfully. All
results and reports from ILS Toolsuite and IMA-Toolchain
shall not show any errors and should not show any warnings.
2) Legacy application
The legacy application is a simple system function, which is
hosted parallel to the HLS on the CPM and IOMD. It is
consisting of
traditional
ARINC653-partitions
and
configuration files without using the MW services.
C. Selective Middleware (Module)
This scenario shall show the module internal functionalities
and successful operation of the MW especially on the CPM
modules. Implemented applications are executed sequentially
on the same module, but without any unintended interference
to each other.
IV.
DEMONSTRATION SCENARIOS
In this section nine demonstration scenarios are defined,
which are mandatory to verifiy the Selective MW approach.
The scenarios cover the process integration, configuration and
full operability of the hosted system functions on the industrial
hardware.
A. Process Integration
Our research carries out to integrate the ILS Toolsuite by
interfacing the input and output files to the IMA development
process. The ILS Toolsuite is used to transform the input
AC_ICDs received from the Module Integrator and System
Designer into the ILS Toolsuite format to enable modelling of
the ILS TopLevel model following the functional
specification. The output AC_ICDs shall be automatically
generated and used for module configuration without any
manual modification as depicted in Fig. 5.
This scenario, therefore, shows the compatibility of the
generated configuration files from ILS Toolsuite to the
certified IMA-Toolchain. This will be achieved by importing
original and incomplete input AC_ICDs into the ILS
Toolsuite, complete the ILS TopLevel Model, and generate
the complete output AC_ICDs. The output AC_ICDs are fed
into the original industrial IMA-toolchain. The generated
output AC_ICDs shall work for the module configuration
without any error. To guarantee that the certified IMAToolchain remains untouched, delivered checksums from the
module supplier are compared with the freshly installed IMAToolchain checksums before and after the configuration
process. The result shall show that both checksums are
identical.
Entry conditions for this scenario are the generation of all
relevant configuration files (including HLS binary, MW
binaries and Legacy application binaries) and the demonstrator
components to be in the operating condition. In the first step,
all modules shall be configured correctly through ILS
Toolsuite and IMA-Toolchain, as described in the specification
documents. The second step is to start the demonstrator to
normal operation12 and demonstrating the HLS functionalities
on the one hand and the operation of the legacy application on
the other hand. Both applications should operate without any
restrictions.
D. Selective Middleware (Network)
The demonstrator consists of modules running the MW (CPM
and IOMD) and modules not running MW (RDC).
Functions of the Flexible Platform that are not covered by the
RDC functionality (parts of the MW) are, therefore, allocated
on the CPM. The RDC are configured via the ILS Toolsuite
and do not host ILS-specific software. Only the software
generated by the IMA-Toolchain via AC_ICD is loaded. The
Flexible Platform is expected to work without restrictions to
the middleware functionality in this environment.
The entry condition here is the same as presented in c)
Selective Middleware (Module) and the demonstrator should
be in an operable state. Because of the description above this
scenario shall validate that CPM get raw sensor signals resp.
from RDC collected data via AFDX network. The procedure
is to review the flaps lever’s transmitted data from RDC via
Wireshark and to compare them with the data on the CPM
12
The demonstrator is in the state of normal operation if all
modules are not be degraded and finished their initialization
phase.
data pool via SPY. Within the opportunity, we can also see the
unified signals prepared from implemented Flexible Platform
in the data pool.
IMA-Toolchain does not show any errors and should not show
any warnings for the CPM on the result of this scenario.
E. ARINC653P4 Compatibility
The used CPM module operating system provides solely
ARINC653P4. The Flexible Platform should be run on an
ARINC653P4 compatible OS without any modifications to the
OS.
Because the full operability of the MW on CPM OS in C) and
D) was demonstrated, we are using the delivered checksum13
of the CPM OS to prove the compatibility. Checksum of the
delivered CPM OS should be generated. After starting the
demonstrator and checking the normal operation of the HLS,
both checksums should be compared. As the result both
checksums must be checked as identical.
F. Monitoring and Manipulation tool (SPY)
Triggering and manipulating data during the system operation
is required to show the internal behavior of the system
components. With the SPY-technology of the Flexible
Platform, it is possible to monitor and manipulate the defined
parameters of the MW instance in the demonstrator. This
scenario demonstrates that the functionality is available via
AFDX too.
To demonstrate this scenario, the demonstrator should be
available within all components. The engaged test system
includes all relevant tools. In addition, SPY-Server and SPYClient are capable to communicate via the AFDX network.
The demonstration example for the SPY functionality is the
verification of the HLS function on the demonstrator. It
consists of test cases such as the robustness tests of the HLS
behavior in case of a data failure, e.g. the flaps lever (CSU)
generating wrong position pattern bits. During the
demonstrator operation, the input data value of the flap lever
will be manipulated without moving the flaps lever position.
To ensure the reaction of the application, on two cycles after
manipulation, the generated target position command should
be monitored. We expect that the defined scenario is fully
executable via the SPY tool.
G. Simplex-minded system function
Within the MW, it is possible to reduce the system function to
bare command and control laws. The platform management is
realized in the instantiated MW. Hence, the new system
function is developed as simplex-minded. The scenario
validates that no system management code is integrated
manually.
To review the simplex-minded feature the HLS command law
is developed as a Simulink model. The Simulink model
includes only relevant single signals and mechanisms without
13
It is provided from Operating System Supplier.
redundancy or other management components. Next, to ensure
that the redundancy management is available nonetheless, the
redundant RDC shall be degraded successively. The easiest
way is to generate power interrupts of the RDC by using a
relay board that controls the modules power supply.
Randomly the RDC get power off until the next-to-last
module. Reviewed are the generated signals e.g. target
position command and its Quality-of-Service information.
Within two operated modules the signals QoS (validity) must
not be degraded. After the next-to-last module is lost, the QoS
it shall degrade. While losing all redundancy, no new
commands shall be generated and the default value (e.g. hold
on last commanded signal value) shall be forwarded. In
addition, as final reaction in case of this failure (represents
uncommand movement in HLS specification) the POBs and
WTBs shall be locked.
The next point to demonstrate is generally to meet the required
reaction time in case of failure by e.g. Flap asymmetry or Flap
Overspeed. This point is referenced to Elmahdi’s evaluation
[24].
H. xLane Consensus
This scenario shall demonstrate that a consensus between the
two CPM lanes (logical similar dual lane module) can be
established and it respects all timing constraints of the system
function requirements on intra module level. Consensus means
that both CPMs produce the same output signals in the same
logical cycles as long as no degradation occurs, which is
important for the integrity of a dual lane CPM.
The appreciation for xLane Consensus is to ensure the data
consistency between two lanes. First proving the normal
operation should be provided for the HLS within all
redundancy signals on the CPM. Then required signals for
consolidation of such redundant signals (calibrated airspeed
and flaps lever signals) will be manipulated in one lane.
Holding on the manipulated lane state, above view cycles,
then CPM shall go in a safe state (isolated state). It is
important to note that the required validation time and
confirmation time to detect this failure is depends on the
integrated system function. In case of the demonstrated HLS,
the validation time of such failure shall be between 40 and
50ms and the confirmation time between 400 and 500ms.
We are expecting that the xLane Consensus between two
standalone modules (CPM-lanes in our case) is achieved and
the synchronization mechanism validated at MW layer.
I. xCPM Consensus
This scenario shall demonstrate that there is consensus
between all asynchronous dual lane CPM. An asynchronous
AFDX network communication is used for the platform-wide
redundancy management base on distributed decision-making
mechanisms. Each CPM generates its own decisions, but after
data exchange come to a common decision. Therefore, a
consensus between all CPM is required (called xCPMconsensus). It shall be established in a short period of time due
to failure detection and error handling requirements. In this
demonstration scenario, a Master-Slave change should be
demonstrated. After a demonstrator cold-start, one of the CPM
is in the Master and the other one is in the Slave state
depending on which CPM started firstly. After normal
operation of the demonstrator, the executed CPM as Master
gets a manual power interrupt. After a maximum of 12 cycles
since power interrupt, the previous Slave CPM shall change to
Master. Then the powered off module will be started again,
and it gets the Slave state after a maximum of 12 cycles since
the module enters normal operation state.
V.
SUMMARY AND OUTLOOK
This paper presents a demonstrator with industrial DIMA
modules, operating system and IMA-Toolchain for the
verification of the selective integration of the Flexible
Platform in the IMA ecosystem. This paper introduces the
Selective Middleware approach and its general usage resp.
benefits. A high-lift system designed by using the SMW
approach and is allocated in parallel to a traditional
ARINC653 application on the DIMA architecture. The highlift system function is split into command law allocated on
CPM and into control law allocated on IOMD. This split
facilities the integration of the high-lift system in respect of
the time constraints for the monitoring functions. Furthermore,
command law and control law are established simplex-minded
because the system management for high-lift components is
realized in the middleware. Nine mandatory demonstration
scenarios are defined to proof the SMW approach and the ILS
Toolsuite integration into IMA development process. Since
the presented demonstrator shall verify the SMW approach,
the demonstration scenarios are defined as the acceptance tests
on the final stage of the project.
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
The next work package is the entire evaluation of the Selective
Middleware approach on DIMA architecture by using the
defined demonstration scenarios and the demonstrator. A
commonly proof concept of the safety related to reliability and
availability is in the pipeline for the SMW approach.
[19]
[20]
[21]
ACKNOWLEDGEMENTS
The German Federal Ministry for Economic Affairs and
Energy (BMWi) has funded this research within the LuFo V-2
program and the AVATAR project.
[22]
[23]
REFERENCES
[1]
[2]
[3]
[4]
[5]
ARINC Specification 653, Avionvics Application Software Standard
Interface, 2005
ARINC Specification 664 P7, Aricraft Data Network Part 7 Avionics
Full Duplex Switched Ethernet (AFDX) Network, 2005
RTCA, DO-297 Integrated Modular Avionics (IMA) Development
Guidance and Certification Considerations, 2005.
T. Gaska, C.Wakin, Y. Chen, „Integrated Modular Avionics-Past,
Present and Future“, in 2015 IEE A&E SYSTEMS MAGAZINE.
H. Butz, “The Airbus approach to open Integrated Modular Avionics
(IMA): Technology, Methods, Processes and Road Map”, at AST
2007 WORKSHOP ON AIRCRAFT SYSTEM TECHNOLOGIES.
[24]
[25]
[26]
T. Maret and M. AlMEIDA, “ASHLEY (Avionics Systems Hosted on
a distributed modular electronics Large scale dEmonstrator for
multiple tYpes of aircraft)”, in 2016 (published) AERODAYS 2015
BOOK.
R. Wolfig, M. Jakovljevic, “Distributed IMA AND DO-297:
ARCHITECTURAL, COMMUNICATION AND CERTIFICATION
ATTRIBUTES”, in 2008 IEEE/AIAA 27nd Digital Avionics Systems
Conference (DASC).
H. Butz, “Open Integrated Modular Avionic (IMA): State of the Art
and future Development Road Map at Airbus Deutschland,” in
Proceedings of the 1st International Workshop on Aircraft System
Technologies, 2007, pp. 211–222.
C. B. Watkins, “Integrated Modular Avionics: Managing the
Allocation of Shared Intersystem Resources,” in 25th Digital
Avionics Systems Conference, 2006 IEEE/AIAA, 2006, pp. 1–12.
B. Annighöfer and F. Thielecke, “A systems architecting framework
for Distributed Intgegrated Modular Avioncs”, in 2014 Deutscher
Luft- und Raumfahrtkongress 2014, DocumentID: 340030.
C. Efkemann, J. Peleska, “Model-based Testing for the Second
Generation of Integrated Modular Avionics”, in 2013 European
Community’s Seventh Framework Programme (FP7/2007-2013).
R. Fuchsen, SYSGO AG, Klein-Winternheim „How to address
certification for Multi-Core based IMA platform: Current Status and
potential solutions”, in 2010 IEEE/AIAA 29nd Digital Avionics
Systems Conference (DASC).
Z. Quan and W. Shihai, “IMA Reconfiguration Modelling and
Reliability Analysis based on AADL”, in 2014 IEEE 4th Annual
International Conference on Cyber Technology in Automation,
Control, and Intelligent Systems (CYBER).
B. Annighöfer, “Model-based Architecting and Optimization of
Distributed Integrated Modular Avionics,” Hamburg University of
Technology, 2015.
B. Annighöfer and F. Thielecke, “A systems architecting framework
for optimal distributed integrated modular avionics architectures,”
CEAS Aeronautical Journal, pp. 1–12, 2015
B. Annighöfer, E. Kleemann, and F. Thielecke, “Automated
Selection, Sizing, and Mapping of Integrated Modular Avionics
Modules,” in 32st Digital Avionics System Conference, Syracuse,
NY, USA, 2013.
B. Annighöfer, E. Stallkamp, and F. Thielecke, “Eclipse Framework
for an Integrated IMA Tool Chain,” in SAE 2011 AeroTech Congress
& Exhibition, October 2011, Toulouse, France, 2011.
B. Annighöfer and F. Thielecke, “Multi-Objective Mapping
Optimization for Distributed Modular Integrated Avionics,” in 31st
Digital Avionics System Conference, Williamsburg, VA, USA, 2012.
B. Annighöfer and F. Thielecke, “Network Topology Optimization
for Distributed Integrated Modular Avionics,” in 33rd Digital
Avionics System Conference, Colorado Springs, CO, USA, 2014.
B. Annighöfer, “Model-driven development and simulation of
Integrated Modular Avionics (IMA) architectures,” in ASIM,
Heilbronn, 2018, no. 1395.
B. Annighöfer, E. Kleemann, and F. Thielecke, “Model-based
Development of Integrated Modular Avionics Architectures on
Aircraft-level,” in Deutscher Luft- und Raumfahrtkongress, Bremen
27. - 29. Sept. 2011, Bremen, 2011, no. 1395.
B. Annighöfer and F. Thielecke, “Supporting the Design of
Distributed Integrated Modular Avionics Systems with Binary
Programming,” in Deutscher Luft- und Raumfahrtkongress, Berlin
10. - 12. Sept. 2012, Berlin, 2012.
L.Kitoko, L. Klein, G. Ried, Liebherr-Aerospace Lindenberg
Germany, “Outboard flaps control system based on the avionics
deterministic fault-tolerant data bus LTTP”, in 2008 IEEE 6th
Industrial Informatics, International Conference.
M. Elmahdi, Distributed Architecture of an IMA-based High-lift
Control System, München (Germany): Institut für Luftfahrtsysteme
der Universität Stuttgart, Dr. Hut.
Anada C.M., S. Nair, and Mainak G.H., “ARINC 653 API and its
application-An insight into Avionics System Case Study”, in 2013
Defence Science Journal, Vol. 63, No. 2, pp. 223-229.
W. Xu, Z. Xiong, C. Gong, “A method of Integrated Modular
Avionics System Configuration Data Management”, in 2015
IEEE/AIAA 34nd Digital Avionics Systems Conference (DASC).
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
Cary R. Spitzer, Digital Avionics Handbook, Second Edition, Richard
C. Dorf, CA: University.
R.Reichel, S. Görke, F. Cake, S. Polenz, R. Riebeling,“Flexible
platform approach for fly-by-wire systems“ in 2013 IEEE/AIAA 32nd
Digital Avionics Systems Conference (DASC), pp. 2C5-1-2C5-16.
S. Korn, R.-R. Riebeling, S. Görke, R. Reichel, „Flexible platform
approach for CS27/29 Fly-By-Wire systems“, in 2013 39th European
Rotorcraft Forum (ERF).
F. Kraus, T. Belschner, R. Reichel, “A methodology for the Flexible
Platform Technology for Fly-By-Wire systems“, AST 2017.
T. Belschner, P. Müller, F. Kraus, and R. Reichel, “Automated
generation of certification relevant documentation for a distributed
avionics platform approach,” in 2016 IEEE/AIAA 35th Digital
Avionics Systems Conference (DASC), 2016, pp. 1–10.
S. Görke, R. Reichel, and S. Hesse, “A generic platform for safetycritical applications in General Aviation,” in 2011 Aerospace
Conference, 2011, pp. 1–9.
S. Görke, R. Riebeling, F. Kraus, and R. Reichel, “Flexible Platform
Approach for fly-by-wire Systems,” in 32st Digital Avionics System
Conference, Syracuse, NY, USA, 2013.
S. Hesse, R. Reichel, and S. Görke, “Platform-based Realization of
Safety Relevant Systems,” in 3rd CEAS Air&Space Conference / 21st
AIDAA Congress, Venedig, 2011.
M. Kern, S. Görke, and R. Reichel, “Ein Fly-by-wire System als
Instanz einer Flexiblen Plattform - Konzeption Eines Systems Für Ein
Geschäftsreiseflugzeug,” in Deutscher Luft- und Raumfahrtkongress,
Augsburg 16. - 18. Sept. 2014, Augsburg, 2014.
F. Kraus, T. Belschner, and R. Reichel, “A Methodology for the
Flexible Platform Technology for Fly-by-wire Systems,” in AST
2017, 2017.
R. Reichel, S. Görke, F. Cake, S. Polenz, and R. Riebeling, “Flexible
Avionics Platform,” in Deutscher Luft- und Raumfahrtkongress,
Bremen, 2011.
T. Belschner, P. Müller, F. Kraus and R. Reichel, „Automated
Generation of Certification Relevant Documentation for Distributed
Avionics Platform Approach“, submitted for DASC 2016 in
IEEE/AIAA 35nd Digital Avionics Systems Conference (DASC), pp.
1-8, 2016.
P. Mueller, T. Belschner, M. Lehmann, R. Reichel, „ AAAPROCESS-A NEW APPROACH TO AFFORDABLE FLY-BYWIRE SYSTEMS FOR CS23 AIRCRAFT“, in 2018 IEEE/AIAA
EAS Aeronautical Journal 9 (1), S. 113–122. DOI: 10.1007/s13272018-0282-7.
F. Cake, “Supervisor für eine komplexe verteilte Avionikplattform“,
in 2016 München, Institut für Luftfahrtsysteme der Universität
Stuttgart, Dr. Hut
B. Lüttig, B. Annighöfer, R. Reichel, „A Service Provisioning Layer
Enabling Simplex-Minded Function Development on Integrated
Modular Avionics Hardware“, in 2018 IEEE/AIAA 37 nd Digital
Avionics Systems Conference (DASC), in press.
J.-P. Kühn, T. Trachsler, B. Annighöfer, R. Reichel, „Q2 Algorithm:
A Robust Communication for standardized Redundancy Management
with AFDX“, in 2017, Detusch Luft- und Raumfahrtkongress,
München
M. Fervel, A. Lecanu, A. Maussion, and J. Aubert, “ Aircraft Control
System with Integrated Modular Architecture”, in 2012, Patent
Application Publication, Pub. No.: US 2012 / 0109424 A1, United
States
H. Louada, R. Champagne, and Y. Labiche,”Toward Automating
Interface Control Documents Elaboration and Management”, Tech.
rep. Ecole de technologie superieure (ETS) Montreal and Carleton
University Ottawa, Sep. 2014
B.Kornek-Percin, B. Petersen, and M.Reichle, “New IMA
architecture approach based on IMA resources,” in 2015 IEEE/AIAA
34nd Digital Avionics Systems Conference (DASC).
O’Connel, Brendan Anthony, Achieving fault tolerance via robust
partitioning and N-Modular Redundancy, Master’s thesis (Cambridge,
MA: Massachusetts Institute of Technology, February 2007).