Sie sind auf Seite 1von 434

System Testing in the Avionics Domain

von Aliki Ott

Dissertation

zur Erlangung des Grades einer Doktorin der


Ingenieurwissenschaften
– Dr.-Ing. –

Vorgelegt im Fachbereich 3 (Mathematik & Informatik)


der Universität Bremen
im Oktober 2007
Datum des Promotionskolloquiums: 18.12.2007

Gutachter: Prof. Dr. Jan Peleska (Universität Bremen)


Prof. Dr. Bernd Krieg-Brückner (Universität Bremen)
Zusammenfassung

In der Vergangenheit bestanden Flugzeugsysteme aus (weitgehend) unabhängigen Steuerelemen-


ten und dazugehörigen Aktuatoren und Sensoren, die jeweils für ihre spezifische Aufgabe im Sys-
tem entwickelt wurden. Um bei neuen Flugzeugentwicklungen den gestiegenen Anforderungen
und dem erweiterten Funktionsumfang gerecht werden zu können, basieren moderne Flugzeug-
systeme auf dem Architekturrahmenwerk Integrated Modular Electronics, das eine Kombination
aus verschiedenen Komponenten zulässt: für den nicht sicherheitskritischen Bereich können vor-
handene, nicht für die Luftfahrtindustrie entwickelte Komponenten verwendet werden; für sicher-
heitskritische Flugzeugfunktionen wird Integrated Modular Avionics (IMA)-Technologie einge-
setzt. Um die IMA-Architektur modular, offen und sehr flexibel zu halten, basiert sie auf gemein-
sam nutzbaren, standardisierten Plattformen (den IMA-Modulen) und standardisierten Netztech-
nologien, die beide speziell für die Anforderungen in der Luftfahrtelektronik – aber unabhängig
von den Aufgaben in spezifischen Flugzeugsystemen – entwickelt wurden. Für das jeweilige Flug-
zeugsystem bedeutet dies, dass vormals aufgabenspezifische Steuerelemente durch mit anderen
Systemen gemeinsam genutzte IMA-Module ersetzt werden. Da diese Veränderungen auch Aus-
wirkungen auf den gesamten Entwicklungs- und Prüfprozess haben, müssen neue Abläufe defi-
niert und passende Methoden und Werkzeuge entwickelt werden.
Die vorliegende Arbeit betrachtet die oben skizzierte Entwicklung aus zwei Blickwinkeln: Zum
einen gibt der Systems-Engineering-Teil eine Übersicht über die Abläufe und Methoden im Allge-
meinen, wie sie bei der Entwicklung und dem Testen von Flugzeugsystemen Anwendung finden,
und beschreibt zudem, wie sich die Technologien und die Prozesse – speziell im Bereich System-
testen von Flugzeugen – verändert haben. Zum anderen vertiefen zwei Fallstudien die zuvor be-
schriebenen Testaktivitäten in zwei neu identifizierten Testbereichen.
Im Systems-Engineering-Teil dieser Arbeit wird beschrieben, wie heutige Flugzeugsysteme ent-
wickelt werden und wie sich dies mit der Entwicklung hin zu IMA-Technologie verändert hat. Da-
bei werden jeweils zwei Perspektiven (die Systemsicht“ und die Prozesssicht“) gewählt, um eine
” ”
umfassende Betrachtung des Themas Systemtesten in Flugzeugen zu ermöglichen und außerdem
die konzeptuelle Basis für die Fallstudien zu liefern. Für die Systemsicht“ fasst die vorliegen-

de Arbeit das Wissen über Flugzeugsysteme bezüglich Architekturmodelle, Redundanzkonzepte,
verwendete Typen von Plattformen und Netztechnologien zusammen und beschreibt, wie sich die-
se verändert haben. Der Schwerpunkt liegt dabei auf IMA-basierten Systemen und den speziellen
Eigenschaften von IMA-Modulen. Für die Prozesssicht“ werden die Entwicklungs- und Testakti-

vitäten auf allen Ebenen (von einzelnen Komponenten bis hin zum Flugzeug als Ganzes) betrachtet
und die Unterschiede aufgezeigt, die sich aus der Verwendung von unterschiedlichen Architektur-
modellen oder der Nutzung verschiedenen Plattform ergeben. Für IMA-basierte Systeme werden
dabei zwei neue Testbereiche diskutiert, die beide unabhängig von spezifischen Flugzeugsyste-
men sind: das Testen von einzelnen IMA-Plattformen und das Testen des Kommunikationsflusses
in einem Netz aus IMA-Modulen.
Die Fallstudien im zweiten Teil dieser Arbeit vertiefen jeweils einen möglichen Ansatz für
diese beiden Testbereiche. Die erste Fallstudie beschreibt eine Testsuite für das automatisier-
te Testen von einzelnen IMA-Modulen ohne Anwendungssoftware. Die Testsuite ermöglicht es,
konfigurations- und anwendungsunabhängig die Einhaltung des in der ARINC 653-Spezifikation
erlaubten Verhaltens zu prüfen und die Konfigurierbarkeit des IMA-Betriebssystems zu verifizie-
ren. Besonders eingegangen wird in der vorliegenden Arbeit auf die Verwendung von generischen
Vorlagen für Testspezifikationen, die nach der Instantiierung für verschiedene (Test-)Konfigura-
tionen als separate Testfälle ausgeführt werden können. Außerdem werden weitere Details zur

iii
iv

praktischen Umsetzung diskutiert. Die Anwendung der Testsuite im Forschungsprojekt VICTO-


RIA sowie die in der Arbeit vorgenommenen Untersuchungen bestätigen, dass das in der Testsuite
umgesetzte Vorgehen gut für automatisierte Hardware-in-the-loop-Tests von IMA-Plattformen ge-
eignet ist und zudem signifikant dazu beiträgt, eine – im Vergleich zum manuellen Testen – höhere
Testabdeckung zu ermöglichen; ein Ergebnis von dem insbesondere auch bei Regressionstests pro-
fitiert werden kann.
Die zweite Fallstudie stellt einen Ansatz zum Testen des Kommunikationsflusses in einem Netz
aus konfigurierten IMA-Plattformen vor, der es gestattet, alle möglichen Anwendungsinteraktio-
nen zu testen, die von der Spezifikation des IMA-Moduls sowie der Netzkonfiguration (d.h. ei-
ner bestimmten Kombination von Modulkonfigurationen) erlaubt werden. Im Rahmen dieser Ar-
beit wird dabei insbesondere ein Algorithmus entwickelt, der all diese Testfälle generieren kann.
Es wird weiterhin untersucht, wie diese Testfälle (nach vorgegebenen Kriterien) priorisiert wer-
den können, so dass die zur Verfügung stehende Testausführungszeit für die wichtigen Testfälle
verwendet werden kann. Die in der Arbeit dargelegte Bewertung dieses Ansatzes bestätigt die
Notwendigkeit eines automatisierbaren Generierungsalgorithmus und zeigt dabei auch, dass noch
effektivere Priorisierungsfunktionen erforderlich sind – insbesondere für realistische (d.h. recht
komplexe) Netzkonfigurationen –, für deren Ausgestaltung sie Hinweise gibt.
Abstract

Traditionally, avionics systems consisted of several independent or loosely coupled special-to-


purpose controllers which were each developed by the respective system supplier. To deal with
the more demanding requirements and additional feature requests for new aircrafts, current avion-
ics systems are based on the framework of integrated modular electronics which allows to use
commercial-of-the-shelf products for less critical functions and uses integrated modular avionics
(IMA) technology for safety-critical avionics functions. This integrated avionics architecture is
modular, open and highly-flexible. It is based on common standardized platforms (the IMA mod-
ules) and standardized aircraft networking technology. For the avionics systems, this means that
most special-to-purpose controllers are replaced by shared IMA platforms which are developed
independently of the respective systems. Since this evolution affects the entire development, new
processes and means for the development and the verification and validation of avionics systems
are required.
This thesis addresses this evolution from two angles: Firstly, a systems engineering part introduces
the general processes and approaches to be considered when developing and testing avionics sys-
tems and describes how the technology and the development processes have evolved, particularly
with respect to system testing in avionics. Secondly, two case studies detail the described general
testing activities during system integration for two newly identified testing areas.
In the systems engineering part, this thesis describes how avionics systems are currently developed
and discusses the effects of evolving towards integrated modular avionics. To provide an encom-
passing reflection of system testing in avionics and deliver the conceptual foundation for the case
studies, both are addressed from a “system point of view” and a “process point of view”. For the
former, this thesis assembles the knowledge about avionics systems with respect to architecture
models, redundancy concepts, used platform types, and common aircraft networking technologies
and describes how these have evolved. The focus is on IMA-based systems and the specific char-
acteristics of IMA platforms. For the latter, this thesis introduces the development and testing
activities from aircraft level to equipment level and elaborates on the differences arising from the
chosen avionics architecture model and the used platform types. For IMA-based systems, it re-
veals two new testing areas which are both independent of specific avionics systems: Testing of
single IMA platforms and testing the communication flow in a network of IMA platforms.
One possible approach for each of these two testing areas is addressed by case studies in the second
part of this thesis. The first case study describes a test suite for automated testing of bare IMA
platforms which allows to verify the behavioral compliance with the ARINC 653 specification and
with the configurability of the IMA module’s operating system, independently of a specific module
configuration or the behavior of specific system applications. In particular, this thesis elaborates on
the test suite’s approach of providing generic test specification templates which can be instantiated
for many different module configurations and discusses the further implementation details. The
implementation experience and the final assessment confirm that the approach is well suited for
automated hardware-in-the-loop testing of bare IMA platforms and contributes to a significantly
higher test coverage (compared to manual testing within the same execution time) – also for each
round of regression testing.
The second case study presents an approach for testing the communication flow in a network of
configured IMA platforms in order to verify that all interactions allowed by the IMA platform
specification and the respective combination of IMA platform configurations are possible. The
thesis elaborates on an algorithm for test data generation and investigates means for prioritizing
those test cases to limit the test execution time. The final assessment of the approach confirms
the necessity of an automatable test case generation algorithm but also shows that more effective
priorization functions are essential for realistic, i.e., very complex, networks of IMA platforms.

v
vi
Preface

When developing a new aircraft, the airframer encounters various – partly contradictory – demands
and requirements: The airlines expect new features and other state-of-the-art equipment for im-
proved passenger comfort and increased flight crew support but also to reduce life cycle cost by
getting an economic and maintainable aircraft for reasonable acquisition cost. The regulation au-
thorities expect that the aircraft and all its systems and components are developed and tested in
compliance with the certification requirements. The airframer wants to reduce development cost
and to shorten the time to market without affecting the aircraft’s quality and safety. In addition,
there are many different, mostly safety-critical and complex systems on-board an aircraft which
are required to perform and control the functionality needed for a safe start, flight and landing as
well as for passenger comfort and leisure. While some of these requirements can be dealt with by
improving existing components (e.g., more efficient engines, reduced component weight), others
can only be handled by a combination of means. This includes using new types of components and
networking technology, benefiting from technologies and products developed for other markets,
introducing a new aircraft architecture, and improving and adapting the processes and methods for
system development as well as verification, validation, and certification.
Although this evolution can be observed for each new aircraft development, three major evolution
phases can be distinguished for the development of avionics systems: In the beginning, aircrafts
used a network of several separate and independent controllers which were each only connected to
the respective system’s sensors and actuators. The controllers were special-to-purpose platforms
which used analog communication links for connecting to the peripheral equipment. This indepen-
dent avionics architecture model evolved to a so-called federated avionics architecture model were
the controllers were loosely coupled for information exchange and some analog communication
links were replaced with digital ones. In the latest phase, to support a more flexible architecture,
aircraft development is currently based on the framework of integrated modular electronics (IME)
which allows to use commercial-off-the-shelf (COTS) products for less critical functions and oth-
erwise uses Integrated Modular Avionics (IMA) technology for safety-critical avionics functions.
In the IMA architecture model, most special-to-purpose controllers are replaced by common stan-
dardized platforms (so-called IMA modules) that usually host applications of several systems. For
inter-system communication, either IMA module-internal communication or standardized aircraft
networking technology with guaranteed bandwidth and high availability is used. The advantages
of IMA are manifold: Shared computing resources need less space allocation, reduce the overall
weight and might even lower the power consumption. State-of-the-art standardized communi-
cation technology can reduce the required wiring while still ensuring guaranteed bandwidth and
high availability and providing a well-defined application-layer communication protocol. Stan-
dardized shared platforms can be developed independently of the systems which avoids redundant
platform development effort and costs for each system. In addition, maintenance for the airlines is
simplified because only few different types of platforms have to be held available.
Despite these advantages, the use of IMA also has a major impact on the development and verifica-
tion and validation processes and means: For the development process, this includes new aircraft
architecture concepts, new approaches for functional grouping of aircraft functions into systems,

vii
viii PREFACE

new responsibilities for developing the avionics platforms and the system software, and new meth-
ods applied for design and requirements definition. For the verification and validation process, the
main impact comes from the use of shared computing resources and the new allocation of respon-
sibilities within the development process. The former requires the development of new means for
ensuring the partitioning (i.e., the isolation of the systems hosted on the same platform) and the
availability of the specified communication capacity. The latter requires to develop new processes,
methods, and tools for handling the partial shift of the hardware/software integration testing for
each subsystem from the supplier side to the integrator (i.e., the aircraft manufacturer). Moreover,
in case of problems and system malfunction, new processes and methods have to be available to
complement the fault localization because problems can be caused by “components” delivered by
different suppliers: For example, by the shared resources’ hardware or software, the allocation of
resources, the system software, the system design, or the network configuration.

Objective

This thesis addresses the aforementioned topics in two ways: Firstly, it describes – from a sys-
tems engineering point of view – the development and the verification and validation (V&V) of
avionics systems and addresses in more detail the interdependencies of IMA-based avionics sys-
tems. Moreover, it introduces the new processes and methods to be considered when developing
and testing systems based on integrated modular avionics. Secondly, the thesis details two test
approaches that support fault localization and increase the confidence in IMA-based systems by
testing the IMA platform and the configured communication network, respectively, independently
of any system-specific application software. This means that this thesis combines one system en-
gineering part which compiles information about processes and avionics systems and one part with
detailed considerations concerning the system test approach for avionics systems using integrated
modular avionics. Thus, the systems engineering part with its overview provides the required
foundation to understand and evaluate the pros and cons of the introduced new testing approaches.
The work presented in this thesis has partly been carried out in the research projects VICTORIA
and KATO.

Overview

This thesis is divided into four parts as it is depicted in Fig. 1: Part I provides an introduction
to avionics systems and presents the processes and methods for system development and testing.
This introduction is then further detailed in Part II for avionics systems using integrated modular
avionics. Part III presents as case studies the details of the two testing approaches, the approach
for automated bare IMA module testing and the approach for testing a network of IMA platforms.
Part IV discusses the lessons learned, evaluates the presented approaches and concludes with an
overall summary. The first two parts pertain mainly to the systems engineering part of this thesis
which creates a consistent terminology, coherent process descriptions and the conceptual basis for
further detailing testing approaches in avionics. Thus, Part I and II provide the required foundation
to understand the pros and cons of the new testing approaches addressed in the latter two parts.
In the introduction to avionics systems (Part I), Chapter 1 addresses the general development
process for avionics systems and also discusses the impact of the chosen architecture and the
used platforms. For this purpose, the chapter introduces the characteristics of avionics systems,
compares the main architecture models and basic redundancy concepts, provides a comparison
of different platform types, and briefly discusses different aircraft networking technologies. This
chapter is complemented by the verification and validation considerations in Chapter 2. After
briefly subsuming methods for verification and validation, this chapter focuses mainly on testing
ix

Part I – Introduction to Avionics Systems

Chapter 1 Chapter 2
Development of Avionics Systems Testing of Avionics Systems

Part II – Avionics Systems using Integrated Modular Avionics

Chapter 3 Chapter 4 Chapter 5


Introduction to IMA Platforms System Architectures using IMA Testing of Systems based on IMA

Part III – Case Studies

Chapter 6 Chapter 7
Automated Bare IMA Module Testing Approach for Testing a Network of
IMA Platforms

Part IV – Lessons Learned

Chapter 8 Chapter 9
Evaluation of the Test Suite for Evaluation of the Approach for
for Automated IMA Platform Testing Testing a Network of IMA Platforms

Chapter 10
Conclusion

Figure 1: Overview of the Thesis

and introduces the general approach for aircraft integration and the respective testing activities.
For testing, the test design documents and the selection of test cases and test procedures are an
essential part. In particular, the specification techniques used in the test design documents lead to
different restrictions regarding test data generation, test execution, and means for test evaluation
and error diagnosis. Since this chapter focuses on testing as one of the most promising implemen-
tation verification methods that allow extensive automation, different specification techniques are
assessed with respect to automated testing.
Based on the introduction in the first part, Part II provides further details for avionics systems
using integrated modular avionics (IMA). Chapter 3 introduces IMA platforms as the key part of
IMA-based system architectures and describes their hardware characteristics as well as the IMA
operating system API specified in the ARINC 653 specification. Since IMA platforms shall be
usable for many different purposes and, therefore, have to be highly configurable by nature, this
chapter also presents the IMA module configuration tables as they are used in this thesis and
discusses configuration responsibilities and configuration change management and their impact
on developing application software for IMA platforms. To provide a deeper understanding on
the usage of IMA platforms, Chapter 4 then presents the characteristics of IMA-based system
architectures. With these details at hand, the required change of the system engineering processes
– and particular of the system integration and testing approach – is further detailed in Chapter 5.
In addition, the chapter elaborates on two newly introduced testing areas, testing single IMA
platforms and testing a network of IMA platforms, and discusses the requirements of test benches
for such tests.
Part III comprises two case studies that address the aforementioned newly introduced testing areas.
Chapter 6 describes a test suite for automated testing of bare IMA platforms which allows to verify
the behavioral compliance with the ARINC 653 specification as well as the configurability of the
IMA module’s operating system, independently of a specific module configuration or the behavior
of specific system applications. In particular, the chapter elaborates on the test suite’s approach of
providing generic test specification templates which can be instantiated for many different module
configurations and discusses the details for implementing the approach. For this purpose, it also
describes the environment for automated test execution and test evaluation.
Chapter 7 presents an approach for testing the communication flow in a network of IMA plat-
x PREFACE

forms in order to verify that all interactions (as allowed by the IMA platform specification and the
respective combination of IMA platform configurations) are possible. The chapter elaborates on
an algorithm for test data generation and also investigates means for handling (i.e., reducing or
sorting) the generated test cases if the generation results in too many test cases to be executed in
an automated way within the provided testing time. For assessing the characteristics of the gener-
ation algorithm, a prototype implementation and a set of example networks have been developed.
Furthermore, the chapter discusses implementation aspects of the approach concerning automated
test execution and test evaluation.
Part IV elaborates on the lessons learned and evaluates the case studies presented in the previous
part. Chapter 8 critically analyzes the approach for automated bare IMA platform testing and
assesses the presented test suite implementation. It also compares the approach with the ARINC
653 Conformity Test Specification. For the second case study, Chapter 9 assesses the described
approach for testing a network of IMA platforms and discusses possible improvements. Finally,
Chapter 10 contains the conclusion from the findings obtained in this thesis and discusses future
work.
This thesis is based on an extensive literature study. Throughout the thesis, the main documents
used within each section and suggestions for further reading are summarized in a references para-
graph at the end of the respective section.

Contributions

This thesis – particularly the systems engineering part – creates a consistent terminology and co-
herent process descriptions and, where necessary, adapts the system and process descriptions to
the IMA concept. To support the understanding of processes and workflows, graphical abstrac-
tions accompany the textual descriptions. This thesis is compiled using various publications about
testing, avionic systems, systems engineering, and software engineering for real-time systems,
among others. The respective documents include standards, guidelines, recommended practices,
books, papers and conference material. Each of them usually focuses mainly on one single aspect
– but not necessarily in a coherent way with respect to terminology and process descriptions in
other publications. Moreover, many publications are focusing on the most popular examples (e.g.,
the flight control system) or describe avionics systems and development and V&V processes be-
fore IMA was in use. This thesis combines the coherent documentation of existing work with own
contributions (besides the summary) to approaches for testing IMA-based systems.
The first case study about automated bare IMA module testing describes the (implementation)
concepts of a test suite that has been designed and implemented to verify the compliance of the
IMA platform in an automated way. Using an (almost) fully automated test suite allows to achieve
a higher degree of test coverage (compared to manual testing within the same execution duration),
eliminates many error-prone and time-consuming tasks, and enables to repeat the test execution
(e.g., for regression testing) with only minor manual interactions. The designed test suite uses
generic parts wherever possible. This comprises a generic test application which behaves as com-
manded by external test specifications, test specification templates that abstract from concrete con-
figuration data and can be instantiated for several (appropriate) test configurations, the rule-based
generation of IMA platform test configurations, and a tool chain that instantiates the particular test
procedures of the test suite and supports preparation of the IMA platform under test. The work pre-
sented in this thesis has partly been carried out in the research project VICTORIA. In this project,
the author and her colleagues at the research group Operating Systems and Distributed Systems
at Universität Bremen (Department for Mathematics / Computer Science) have cooperated with
the other project partners, particularly, Verified Systems GmbH and Airbus Deutschland GmbH.
Thus, several people have contributed to the respective findings and results. Concerning this the-
sis, the author has significantly contributed to the design and implementation of the described test
xi

suite which can be embedded in the available testing environment (i.e., the tool chain and the test
system used within the context of the VICTORIA project). This thesis compiles a comprehensive
description of the implementation concepts, problem solutions and achievements. Moreover, it
assesses the approach and the implemented test suite and compares it with other approaches.
This thesis also includes a second case study that describes an approach for testing the communi-
cation flow in a network of configured IMA platforms. This approach addresses a test step that has
been newly introduced for IMA-based system architectures to support the integration of several
systems which share the same set of IMA platforms. Performing this network integration testing,
the multi-system integrator is able to show – independently of the real systems behavior – that
all inter-system communication is possible (within the range of the module configurations and the
module’s specification) and that the network provides its characteristics under any legal operation
conditions (also in case of maximum load). The approach developed in this thesis has a strong
focus on automation: In addition to discussing considerations for automated test preparation, test
execution, and test evaluation, it introduces an algorithm that generates for the specific network
configuration all possible communication behavior schedules, i.e., all possible test cases. More-
over, this thesis also suggests means for focusing the test range in an automated way. As a result,
the otherwise too many test cases are reduced and the remaining ones prioritized according to
well-defined rules so that their execution within the given testing time becomes more realistic.
xii
xiii

Acknowledgments

This thesis reflects the research I have carried out from May 2001 to October 2005 in the research
group Operating Systems and Distributed Systems headed by Prof. Dr. Jan Peleska at Universität
Bremen (Department for Mathematics / Computer Science) and has been finished in the last years
while I was already working in Helsinki (Finland). This thesis would not have been possible
without the support and (direct and indirect) contributions from many people and I would like
to express my gratitude to all of them for their help, their advice, their encouragement and their
patience.
First and foremost, I would like to thank my supervisor Prof. Dr. Jan Peleska for his guidance
and good feedback. The research carried out at his research group and the teaching courses that I
could actively participate in provided an excellent environment for my professional and personal
development. In particular, I am thankful for the possibility to gain detailed insight into the field
of safety critical system development, verification, validation and testing (with focus on testing
of safety-critical systems in the avionics domain). I also appreciate that I got the chance to apply
my acquired knowledge in “real world” projects at Verified Systems International GmbH. Many
thanks also to Dr. Cornelia Zahlten for this opportunity.
Furthermore, I would like to thank Prof. Dr. Bernd Krieg-Brückner for taking the role of the second
reviewer, quite a challenge given the volume of this thesis.
I am glad that I could hold my defense in December 2007, thanks to both reviewers providing their
statements very quickly and finding a time slot on short notice even in the always-busy end-of-year
period.
I also would like to thank all my former colleagues within the research group Operating Systems
and Distributed Systems for the good collaboration and inspiring conceptual discussions. In par-
ticular, I owe many thanks to my office mate and friend Dr. Stefan Bisanz for the countless hours
we have spent together – not only in our nightly sessions – in discussing of concepts, algorithms,
and approaches, designing practical assignments, sharing other teaching-related responsibilities,
and sitting next to each other writing our theses.
The work presented in this thesis – particularly in the first case study – has partly been car-
ried out in the research projects VICTORIA and KATO. In these projects, my colleagues and I
have closely cooperated with the other project partners, particularly, Verified Systems GmbH and
Airbus Deutschland GmbH. I have appreciated the good collaboration in conceptual discussions
and in our implementation efforts which is both reflected in the resulting test suite implementa-
tion. In particular, I would like to thank Christof Efkemann, Hans-Jürgen Ficker, Dr. Oliver Meyer,
Stefan Walsen (Verified Systems International GmbH) and Dirk Meyer (Universität Bremen) and
the colleagues at Airbus Deutschland GmbH which participated in the VICTORIA project.
I also would like to thank Prof. Dr. Ina Schieferdecker (TU Berlin) for her comments on the
generation algorithm in the second case study.
The work on this thesis – as it has been started in Bremen and continued in the last years here
in Finland – had influenced my life for quite a long time and I am grateful for the support of my
husband. I would like to thank Jörg Ott for (proof-)reading and commenting on my thesis and for
his advice and encouragement.
Finally, I would like to thank my parents for encouraging me over the last years and, particularly,
for supporting my decision to study computer science at a time when this was not so “hip”.

Espoo, December 2007


xiv
Contents

Preface vii
Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

I Introduction to Avionics Systems 1

1 Development of Avionics Systems 3


1.1 Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Characterization of Avionics Systems . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Avionics Architecture Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Redundancy Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Categorization of Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.1 COTS Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5.2 Special-to-purpose Platforms . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5.3 IMA Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5.4 Peripheral Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.5 Operating System Requirements . . . . . . . . . . . . . . . . . . . . . . 23
1.6 Categorization of Aircraft Networking Technology . . . . . . . . . . . . . . . . 24
1.6.1 ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6.2 ARINC 629 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6.3 ARINC 664 and AFDX . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.4 Controller Area Network (CAN) . . . . . . . . . . . . . . . . . . . . . . 31
1.6.5 Application-specific Busses and Protocols . . . . . . . . . . . . . . . . . 32
1.7 Development Process – Architecture and Platform Dependance . . . . . . . . . . 33

xv
xvi CONTENTS

2 Testing of Avionics Systems 35

2.1 Overview of Verification and Validation Methods . . . . . . . . . . . . . . . . . 36

2.2 System Test Approach for Avionics Systems . . . . . . . . . . . . . . . . . . . . 39

2.2.1 Platform Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.2.2 Application Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.2.3 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.4 Multi-System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.5 System Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.6 Ground Tests and Flight Tests . . . . . . . . . . . . . . . . . . . . . . . 43

2.3 Test Design Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.3.1 Test Case and Test Procedure Selection . . . . . . . . . . . . . . . . . . 44

2.3.2 Specification Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.4 Test Data Generation, Test Execution and Test Evaluation . . . . . . . . . . . . . 54

2.4.1 Test Data Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.4.2 Test Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.4.3 Test Evaluation and Error Diagnosis . . . . . . . . . . . . . . . . . . . . 57

II Avionics Systems using Integrated Modular Avionics 59

3 Introduction to IMA Platforms 61

3.1 IMA Platform Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.1 IMA Platform Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.2 IMA Operating System and the ARINC 653 API . . . . . . . . . . . . . 63

3.2 Configurability of IMA Platforms . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.2.1 Module-level Configuration Tables . . . . . . . . . . . . . . . . . . . . . 72

3.2.2 Partition-level Configuration Tables . . . . . . . . . . . . . . . . . . . . 75

3.2.3 Configuration Responsibilities and Change Management . . . . . . . . . 79

3.3 Developing Application Software for IMA Platforms . . . . . . . . . . . . . . . 81

4 System Architectures using Integrated Modular Avionics 85

4.1 IMA Architecture at the Aircraft Level . . . . . . . . . . . . . . . . . . . . . . . 85

4.1.1 Analysis of a Sample Aircraft Architecture . . . . . . . . . . . . . . . . 87

4.2 IMA Architecture on System Level . . . . . . . . . . . . . . . . . . . . . . . . . 92


CONTENTS xvii

5 Testing of Systems based on Integrated Modular Avionics 95


5.1 System Test Approach for IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.1 Platform Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.2 Application Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.3 Platform Tests with Application Software . . . . . . . . . . . . . . . . . 98
5.1.4 System Integration / Multi-System Integration . . . . . . . . . . . . . . . 98
5.1.5 System Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.6 Ground Tests and Flight Tests . . . . . . . . . . . . . . . . . . . . . . . 99
5.2 Testing Single IMA Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.2.1 Testing Bare IMA Platforms . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.2 Testing Configured IMA Platforms . . . . . . . . . . . . . . . . . . . . 102
5.3 Testing a Network of IMA Platforms . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.1 Testing a Network of Configured IMA Platforms with Test Applications . 104
5.4 Test Bench for IMA Platform Testing . . . . . . . . . . . . . . . . . . . . . . . 107
5.4.1 Test Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.4.2 Test System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

III Case Studies 117

6 Automated Bare IMA Platform Testing 119


6.1 Test Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.1 Minimum Standard Behavior of the TA Processes . . . . . . . . . . . . . 123
6.1.2 Communication Protocol between TA and Test Specifications . . . . . . 125
6.1.3 Minimum Configuration Requirements . . . . . . . . . . . . . . . . . . 127
6.2 IMA Test Execution Environment . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2.1 CSP Environment for Commanding . . . . . . . . . . . . . . . . . . . . 130
6.2.2 CSP Environment for Semi-Automated Testing . . . . . . . . . . . . . . 139
6.2.3 CSP Environment for AFDX, ARINC 429, CAN, Analog and Discrete I/O 140
6.2.4 CSP Environment for the Communication Flow Scenario . . . . . . . . . 140
6.2.5 General CSP Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.3 IMA Configuration Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.3.1 Configuration Data Generator . . . . . . . . . . . . . . . . . . . . . . . 144
6.3.2 Configuration Data Parser . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.4 IMA Test Specification Template Library . . . . . . . . . . . . . . . . . . . . . 164
6.4.1 Test Procedure Templates . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.4.2 Example for Partitioning Testing . . . . . . . . . . . . . . . . . . . . . . 168
6.4.3 Example for Intra-Partition Communication Testing . . . . . . . . . . . . 172
6.5 Test Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.5.1 Load Generation Environment . . . . . . . . . . . . . . . . . . . . . . . 176
6.5.2 Test Instantiation Environment . . . . . . . . . . . . . . . . . . . . . . . 180
6.6 Test Execution and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.7 Classification of the Observed Errors . . . . . . . . . . . . . . . . . . . . . . . . 184
xviii CONTENTS

7 Approach for Testing a Network of IMA Platforms 187


7.1 Communication Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
7.1.1 Manual Generation of an Example . . . . . . . . . . . . . . . . . . . . . 192
7.1.2 Characteristics of Communication Schedules . . . . . . . . . . . . . . . 197
7.1.3 Representation of Communication Schedules . . . . . . . . . . . . . . . 198
7.2 Generation Algorithm for Communication Schedules . . . . . . . . . . . . . . . 202
7.2.1 Description of the Generation Algorithm . . . . . . . . . . . . . . . . . 202
7.2.2 Influencing and Handling the Generation Algorithm’s Results . . . . . . 204
7.3 Considerations for Implementing the Approach . . . . . . . . . . . . . . . . . . 210
7.3.1 Approaches for Test Execution using Communication Schedules . . . . . 210
7.3.2 Approaches for Test Evaluation . . . . . . . . . . . . . . . . . . . . . . 217
7.4 Assessment of the Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.4.1 Prototype Implementation of the Generation Algorithm . . . . . . . . . . 220
7.4.2 Example Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.4.3 Assessment Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
7.5 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

IV Lessons Learned 241

8 Evaluation of the Test Suite for Automated Bare IMA Platform Testing 243
8.1 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
8.2 Comparison with Other Approaches . . . . . . . . . . . . . . . . . . . . . . . . 249
8.2.1 Comparison with ARINC 653 Conformity Test Specification . . . . . . . 249

9 Evaluation of the Approach for Testing a Network of IMA Platforms 253


9.1 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
9.2 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

10 Conclusion 261
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

V Appendices 267

A CSP 269
A.1 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
A.2 Channels and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
A.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
A.3.1 Modeling Sequences of Events . . . . . . . . . . . . . . . . . . . . . . . 271
A.3.2 Modeling Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
A.3.3 Modeling Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
A.3.4 Modeling Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
A.3.5 Modeling Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
A.3.6 Modeling Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
A.3.7 Additional Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
A.4 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
A.5 Sequences and Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
A.5.1 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
A.5.2 Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
CONTENTS xix

B IMA Test Execution Environment – Examples 275


B.1 CSP Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
B.1.1 CSP Types for Commanding of API Calls . . . . . . . . . . . . . . . . . 275
B.1.2 CSP Types for Communication Flow Scenario . . . . . . . . . . . . . . 280
B.2 CSP Channel Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
B.2.1 CSP Channels for Commanding of API Calls and Scenarios . . . . . . . 281
B.2.2 CSP Channels for Communication Flow Scenario . . . . . . . . . . . . . 295
B.3 CSP Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
B.3.1 CSP Macros for Commanding of API Calls . . . . . . . . . . . . . . . . 296
B.3.2 CSP Macros for Communication Flow Scenario . . . . . . . . . . . . . . 318
B.3.3 General CSP Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

C IMA Configuration Library – Examples 325


C.1 Configuration TEMPLATE01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
C.2 Configuration Config0001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
C.2.1 Configuration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
C.2.2 Resulting Configuration Tables . . . . . . . . . . . . . . . . . . . . . . . 332
C.2.3 Resulting Test Relevant Configuration Data Extracts . . . . . . . . . . . 336
C.3 Configuration Config0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
C.3.1 Configuration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
C.3.2 Resulting Configuration Tables . . . . . . . . . . . . . . . . . . . . . . . 347

D IMA Test Specification Template Library – Examples 361


D.1 Partitioning Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
D.1.1 TO PART 003/test procedure template 03 . . . . . . . . . . . . . . 361
D.2 Intra-Partition Communication Tests . . . . . . . . . . . . . . . . . . . . . . . . 381
D.2.1 TO PARCOM 002/test procedure template 01 . . . . . . . . . . . . 381

E Communication Schedule Examples 387


E.1 Example of a Communication Schedule Set . . . . . . . . . . . . . . . . . . . . 387
E.2 Example of a Sorted Communication Schedule Sequence . . . . . . . . . . . . . 391

F Results of the Generation Algorithm’s Prototype Implementation 395

G Acronyms for Systems and System Components 401

Bibliography 403
xx
Part I

Introduction to Avionics Systems

1
Chapter 1

Development of Avionics Systems

The development process for an aircraft begins at aircraft level and the specification and design
becomes more detailed and comprehensive in each step. Finally, it results in the development of
many different hardware and software items which have to be assembled in the following integra-
tion steps. The development process is accompanied by a verification and validation process used
to check the correctness of each refinement step and to show that the decisions of the development
process have been implemented correctly. Different life cycle models are used to describe an ap-
proximation of the actual systems engineering process – each emphasizing different aspects of the
process. When selecting one or a small subset of possible ones, it has to be considered that (a)
in systems engineering and especially in aircraft systems engineering, many different engineering
disciplines are involved which use different terminology and (b) many thousand engineers poten-
tially even from different countries are assigned to the different task which have to be carried out.
One particular aim of the life cycle model representing the aircraft development process is there-
fore to support the engineers in reducing the likelihood of misunderstanding because of different
terminology by setting up a glossary and by explicitly documenting the requirements, design deci-
sions, interfaces, and test plans. Of course these documents are also necessary for the certification
activities to be passed before the aircraft can enter service.
One well-known graphical representation of the systems engineering process applied for aircraft
development is depicted in Fig. 1.1. This representation follows the basic ideas of the so-called
V-Model ([V-Modell-XT]) which essentially addresses software development which is just one
part of a typical systems engineering process. The ‘V’ is used to emphasize the relationship
between the development and the verification and validation (V&V) process by relating specific
development documents with their associated verification and validation activities. Further, the
‘V’ stresses the top-down approach of the development process and the bottom-up approach of
the V&V process. Its major disadvantage is that it may lead people to understand the life-cycle as
first development and then – with the final implementation at hand – the verification and validation
activities. This separation is obviously not favorable since late validation and verification of high-
level requirements and design can result in late and expensive changes to these documents and
their associated lower-level documents and thus finally to the product itself. However, this is not
intended by the graphical representation as a ‘V’. Other life-cycle models may overcome this lack
of temporal order of activities but focus less on the level of detail and particular documents and
activities.
The basic life cycle model shown in Fig. 1.1 identifies the different levels of detail (aircraft, do-
main, system and equipment level) and assigns the typical requirement and design documents (on
the left hand side) and the associated V&V activities (on the right hand side). Although iterative
(feed-back) cycles within one level and between different levels are not depicted, the V shall not
necessarily imply a strict sequential order of development steps. Particularly, some V&V activities
like test planing, writing of test specifications, and generation of verification-specific hardware or

3
4 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

software have to be performed in parallel to the development of the systems and their hardware
and software to avoid unnecessary delays. Also the close connection between the requirement and
design documents of the development process and the test plans and test specifications used for the
verification activities are not particularly emphasized, but will be addressed later when discussing
testing of avionics systems (Chap. 2) which is one important part of the V&V activities.

Aircraft Functional Requirements Aircraft Certification


Aircraft Level

Dev

s
Route Proving

ces
System Top-Level Aircraft Requirements

elo

Pro
Flight Tests

pm
Top-Level System Requirements Document Domain Level

n
ent

atio
Ground Tests
Functional Requirement Document (FRD)

alid
Pro
System Integration Tests

&V
ces
System Requirements Document (SRD)

n
Multi-System Tests

atio
System Description Document (SDD) System Level

ific
Ver
Purchaser Technical Specification (PTS) System Tests

Equipment PTS Qualification Tests


System/Equipment Development Equipment Tests
Production

Equipment Level

Figure 1.1: Systems engineering model focusing on the different detail levels and listing the asso-
ciated documents and activities.

In this chapter, the development of avionic systems shall be considered focusing on the left hand
side of the ‘V’ and the respective life cycle model sketched above. The general system devel-
opment process is discussed in the following section (Sect. 1.1). The characteristics of avionics
systems are considered thereafter (Sect. 1.2). Avionics systems can follow different architecture
models and redundancy concepts. Therefore, the most-known architecture models are compared
in Sect. 1.3 and the basic redundancy concepts are considered in Sect. 1.4. Different architecture
models also imply the use of different types of platforms and the necessity of different network-
ing technology. A comparison of different platform types and their characteristics is provided in
Sect. 1.5. A categorization of aircraft networking technologies is then considered in Sect. 1.6. The
information gathered in these sections applied to the system development process described in the
following subsection (Sect. 1.1) is then shown more clearly in the end of this chapter (Sect. 1.7).
The right hand side of the ‘V’ – in particular testing as one of the important parts of the V&V
activities – is then addressed in the next chapter (Chap. 2).

1.1 Development Process

The starting point for the development process is the identification of aircraft-level functions, func-
tional requirements and functional interfaces and the specification of the physical aircraft architec-
ture. Typical aircraft functions (as for example listed in [ARP4754], p. 69) include flight control,
ground steering, aircraft aspects of air traffic control, automatic flight control, cargo handling, en-
gine control, collision avoidance, ground deceleration, environmental control, passenger comfort,
communication, guidance, navigation, and passenger safety. Based on the aircraft-level docu-
ments, the aircraft functions are functionally grouped into so-called domains and the related sys-
tems are identified. The process for selecting an appropriate functional grouping out of the range
of possible groupings is often complex and controversial because implementation constraints and
failure effects have to be considered. In the following, we consider a typical generic functional
grouping used for civil aircraft programs based on the domain structure chosen in the VICTORIA
project ([VICTORIA]):
1.1. DEVELOPMENT PROCESS 5

• The flight control domain is composed of systems concerned with flight control and guid-
ance and slat/flap control which get inputs directly from the pilot’s sidestick operations.

• The engine domain comprises the systems which are concerned with electronic engine con-
trol and engine health management.

• The cockpit domain comprises the systems concerned with the management and control of
the cockpit displays used for in-flight and airport navigation.

• The cabin domain subsumes the systems controlling the cabin status with respect to air
conditioning, ventilation, pressurization, fire and smoke detection as well as slides and doors
management.

• The utilities domain includes the systems controlling the fuel flow, landing gears, steering
and braking.

• The energy domain is concerned with the management and control of the power generation
and distribution functions on-board the aircraft.

• The on-board information systems (OIS) domain is concerned with on-board maintenance
and aircraft condition monitoring using information from the cockpit and cabin domain and
provides information (e.g., the airport navigation database) to systems in other domains.

• The passenger and crew member communication and entertainment services (PCES) do-
main is concerned with communication and entertainment services for the passengers and
crew members. This includes crew-related services (e.g., support for passenger comfort and
information, crew communication, cabin management) as well as passenger-related services
(e.g., in-flight entertainment, e-mail and Internet access).

Based on the documents subsuming the aircraft- and domain-level design decisions and require-
ments, the architecture of each system is determined and the respective system requirements are
explicitly linked to the aircraft-level requirements. The system architecture establishes the sys-
tem’s structure and boundaries and defines the interfaces between the system’s items and to the
other systems. As before, more than one candidate architecture may be considered. The selection
of an appropriate system architecture is supported by assessing the implications with respect to
safety requirements, possible error propagation, and business requirements (e.g., resulting weight,
maintainability). Within the system-level documents, the equipment of the respective system is
identified which comprises the hardware (controllers, sensors, actuators) as well as the neces-
sary software (operating systems, applications, firmware). For each such item, detailed technical
specifications and design documents are developed on equipment level which form the basis for
software and hardware development.
From closer examination of the development activities described above, it is apparent that the air-
craft conceptually comprises several domains which each (conceptually and physically) consist of
several systems which may be partitioned into subsystems. These (sub)systems are again com-
posed of hardware equipment which are the physical items installed in the aircraft and the associ-
ated software. This conceptual structure is depicted in Fig. 1.2 where the aircraft is functionally
divided into two domains D1 and D2 . Each domain again is divided into two systems (S 11 and S 12
for domain D1 , S 21 and S 22 for domain D2 ). Each system again consists of two equipment items,
for example, a controller hardware platform and accompanying system software. Each system
and each piece of equipment is specified in separate documents with each document interacting
with the respective higher level document. This means, for example, that in Fig. 1.2 there are
4 system-level requirements and design documents (i.e., 4 SRDs and 4 SDDs) and 8 Equipment
PTS documents. Note that the aircraft level and the domain level are separated conceptually while
the other levels also represent physical separation (i.e., different hardware or different software).
6 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

Therefore, aircraft and domain level are depicted in the ‘V’ of Figures 1.1 and 1.2 with the same
background color while system level and equipment level are represented by different background
colors.

Aircraft
Aircraft
Level D1 D2
Domain
Level
S11 S12 S21 S22

System
Level
E 111
E 112
E 121
E 122
E 211
E 212
E 221
E 222
Equipment
Level

Figure 1.2: Systems engineering model detailing Fig. 1.1 by showing the separation into different
domains, systems and equipment components.

Note that the aforementioned functional grouping means that each system can be assigned only
to one domain although parts of its functionality may also be provided by other systems which
both may contribute to the same aircraft function. The aim of each partitioning step is to reduce
complexity in such a way that the documents remain manageable despite more details being added.
The activities are supported by explicit traceability links between high- and low-level requirements
which are also necessary for measuring the test coverage during the later V&V activities.
Furthermore, the description of the development process is simplified in such a way that it man-
dates a federated architecture with strict assignment of equipment items to systems and domains.
In fact, the development process is influenced by architectural considerations, the required / chosen
redundancy concept, platform characteristics and political decisions (e.g., this domain is devel-
oped here and the others there1 ). To understand the impact of architecture, redundancy concept
and platform type these topics are examined in the following sections: Section 1.3 examines differ-
ent avionics architecture models, Sect. 1.4 considers different redundancy concepts, and Sect. 1.5
compares different platform types. The effects are then summarized in Sect. 1.7 at the end of this
chapter.

References
[ARP4754] deals with the system development processes of highly-integrated or complex avia-
tion systems and elaborates on how to show compliance to a regulator. For the development of
the software part, [DO-178B] describes the guidelines to be followed for development and certi-
fication. The requirements and guidelines for the system design are also addressed in [ABD200].
[VICTORIA] describes the domain structure followed in this thesis as well as the processes and
guidelines followed in the European research project VICTORIA.
1
For the Airbus A380, the development of major parts (wings, cockpit, cabin, landing gears) are built in France,
United Kingdom, Germany and Spain. The systems of the respective domains are developed and integrated under
supervision of Airbus Germany, Airbus France and Airbus UK. The transport of the aircraft parts to the final assembly
location in Toulouse is one of the logistical problems which had to be solved.
1.2. CHARACTERIZATION OF AVIONICS SYSTEMS 7

1.2 Characterization of Avionics Systems


The development process described in the previous section did not focus in detail on a specific
type of system. Nevertheless, avionics systems are typically safety-related hard real-time reactive
systems with different level of criticality. In the following, the characteristics of avionics systems
will be defined.

Safety-related systems. Safety-related systems are characterized as systems whose failure can
result in direct, and possibly very serious, harm to one or more people. Obvious examples of
safety-related systems are nuclear reactor control systems, automotive engine management or
braking system, and most avionics systems (e.g., flight management system). Depending on the
consequences of a system failure, the level of safety criticality is related to the severity of the
potential accident. For civil aircraft systems, RTCA / DO-178B ([DO-178B], p. 7) suggests the
following categories for the software part of avionics systems which can be applied similarly to
describe failures of the systems themselves: catastrophic, hazardous / severe-major, major, minor,
no (safety) effect. Based upon the contribution of a system to a potential failure condition, it is
expected that the development and V&V activities comply with the corresponding failure condi-
tion category. Therefore, each system is often assigned a so-called development assurance level
(DAL) ranging from DAL A to DAL E where level A corresponds to most failure critical and
level E to least failure critical. This means, a level A system failure would cause or contribute to
a catastrophic failure of the aircraft system.
Note that the terms safety-related system and safety-critical system are often used synonymously.
In this thesis, safety-critical system usually implies a system of high criticality in contrast to safety-
related system that may also refer to systems of low criticality.

Real-time systems. Real-time systems can be categorized as hard and soft depending on their
time constraints. Using the definition of Storey ([Sto96], p. 330), hard real-time systems have time
constraints such that the response of the system to a given stimulus must always occur within a
given amount of time. Soft real-time systems have time constraints such that the mean response
time, over a defined period, is less than some specified maximum value.
Most avionics systems are hard real-time systems. The requirement to validate all hard timing
constraints imposes many restrictions on the design and the implementation of the application
software as well as on the architecture of the platform.

Reactive systems. Reactive systems continuously interact with and control (parts of) their en-
vironment in order to perform user-required services. The interaction partners are other systems
or directly controlled equipment like sensors and actuators. Typically, deadlines for reactions are
derived from the required responsiveness of the sensors and actuators monitored and controlled by
the system which shows the close relation of reactive systems to real-time systems.

Fault Tolerance, Fault Avoidance, Fault Removal, Fault Detection. The objective of fault
tolerance is to design a system in such a way that allows the continuation of service in presence of
faults and prevents that faults result in system failure. Fault tolerance can be achieved by choosing
an appropriate system architecture and redundancy concept. Thus it can provide some protec-
tion against random hardware faults and some forms of systematic errors, but usually does not
reduce the impact of specification errors. The number of specification errors can be reduced by
applying fault avoidance techniques. To achieve high dependability, it is essential that the devel-
opment process is followed in a way that ensures the best possible interaction between the chosen
system architecture (and redundancy concept), the various platforms used within the respective
architecture, the application software using the services provided by the respective platforms, and
8 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

the environment which provides certain information and behaves in a specified way. The aim is
to build ‘perfect’ (i.e., faultless) hardware and software components. Fault avoidance is coupled
with fault removal methods, i.e., the verification and validation techniques applied to detect pos-
sible faults. Some systems also provide techniques for on-the-fly fault detection in order to locate
the source of any error and thus to minimize the effects of hardware and software faults. This can
be achieved by fault tolerant systems. In general, it is not possible to avoid all hardware and soft-
ware faults. Nevertheless, it is desirable to design fault tolerant hardware platforms and to apply
adequate fault avoidance and fault removal methods while specifying hardware and software.

In the following sections, factors influencing the development of safety-critical hard real-time
systems by means of a specific architecture (Sect. 1.3) or a redundancy concept (Sect. 1.4) or a
specific platform (Sect. 1.5) are discussed in more detail. Fault removal by verification and valida-
tion techniques with a focus on testing is discussed in the next chapter (Chap. 2). Fault detection
mechanisms in general are not discussed in detail, but considered in Chap. 3 when providing a
detailed overview of one specific platform type and its operating system services.

References
Avionics systems are characterized in all guideline and standard documents referring to the de-
velopment and certification of avionics systems (e.g., [ARP4754], [DO-178B], [ABD200]). Real-
time and safety-critical systems in avionics and other areas are also defined in [Pel96], [Liu00],
[Coo03], [Sto96], [Sto99], among others.

1.3 Avionics Architecture Models

The system architecture defines how the system assembles its subsystems and the related equip-
ment and thus the internal and external interfaces. As we have seen when discussing the char-
acteristics of hard real-time safety-critical systems (i.e., of most avionics systems), the system
architecture has a major impact on

• the real-time and fault tolerance capabilities (together with the chosen redundancy concept),

• the applicability of fault avoidance and fault removal techniques (subject to the chosen plat-
form), and

• non-functional factors like maintainability, resulting weight of hardware and wiring, and the
consequences for power consumption, cooling, etc. (considering as well the chosen platform
types and the redundancy concept).

The selection process for an appropriate system architecture has to consider all these factors.
Before evaluating the aforementioned characteristics in detail, we discuss the evolution of archi-
tecture models (as represented in the literature for example by [Fil03] and [Rus99]).
Different generations of avionics architecture models can be distinguished:

1. Independent avionics architectures are composed of separate and independent controllers2


which are each connected by point-to-point wiring to their dedicated sensors and other pe-
ripheral equipment. Each control system (i.e., controller with its sensors) realizes one func-
tion. The different control systems are not interconnected and thus cannot share sensor
2
The term controller is used to refer to (hardware) platforms with application software executed on the platform.
The term platform refers to a computing system (i.e., hardware) and – if applicable – associated operating system
software. Sect. 1.5 provides a categorization of different platforms.
1.3. AVIONICS ARCHITECTURE MODELS 9

information. As a consequence, fault containment is inherent since fault propagation from


one to another system is not possible. This architecture model represents the first generation
of avionics architectures.
An example of an independent architecture model is depicted in Fig. 1.3.

2. Federated avionics architectures are those in which each system has a dedicated controller3
and the controller hardware is not shared by different systems. The controllers are loosely
coupled to the controllers of other functions, thus fault propagation from function to function
is only possible by interaction which can be detected and tolerated by the software. This
architecture model is the second generation of avionics architectures. It has evolved due to
the need to combine information from different functions in order to provide the expected
functionality.
Figure 1.4 shows an example of a federate architecture model.

3. Integrated avionics architectures (also known as Integrated Modular Avionics) have been
developed to create a modular, open, fault-tolerant and highly-flexible architecture for dig-
ital avionics. Here, standardized computer systems provide a common platform for hosting
several functions. These so-called IMA modules are connected by data busses. Since all
functions hosted on one module share the computing resource and the memory of the re-
spective platform, fault propagation has to be avoided by partitioning mechanisms. By
now, different generations of integrated avionics architectures can be distinguished: the first
ones were applied in Boeing 777 for certain selected functions (see [Mor01], [But05], and
[MS03], p. 334f, among others) and the latest ones in the currently developed Airbus A380
on aircraft level (i.e., for most functions) (see [MS03], p. 336, among others). Apart from
the different application levels, further differentiators are existent. The first generations of
IMA used non-standard or proprietary backplanes or data busses and closed architectures
with single suppliers for the modules, while the newest generation focuses on open archi-
tectures4 , i.e., standardized data busses, and standardized modules from different suppliers.
Furthermore, the first solutions were backplane-based integrated racks (also called cabi-
nets) that integrated distinct so-called line replaceable modules (LRM) that either provide
data processing, I/O or power supply. Today’s IMA modules substitute the cabinet solution
by providing a general purpose avionic controller called Core Processing and I/O Module
(CPIOM) (see e.g., [Die04b], [Die04a]) which use an external power supply unit.
Fig. 1.5 depicts an integrated modular avionics architecture.

The three different architecture models are depicted in Fig. 1.3 (independent architecture), Fig. 1.4
(federated architecture) and Fig. 1.5 (integrated modular avionics). Each figure shows an aircraft
architecture consisting of two domains domain 1 and domain 2. Domain 1 assembles three sys-
tems (system 1 is green, system 2 is pink, system 3 is light blue), domain 2 one system (system 4 is
orange). Each system is connected to its specific peripheral equipment. Interconnection between
the systems is depicted in blue: in the federated architecture model the systems are connected by
point-to-point communication whereas in the integrated modular avionics architecture the IMA
modules are connected by a switched data bus. Not shown is the communication between appli-
cations hosted on the same IMA module. Naturally, the systems are not connected in the indepen-
dent architecture model. The platforms hosting the application software within the independent
architecture (Fig. 1.3) and the federated architecture (Fig. 1.4) may be different (e.g., special-to-
purpose, standardized commercial, commercial-off-the-shelf), while the integrated modular avion-
ics architecture (Fig. 1.5) ideally uses only one type of platform to host the application software –
standardized IMA modules. This representation shall not restrict the use of different types of IMA
3
Note that for achieving fault tolerance this controller can be redundant.
4
Open architecture in this context means (see [MS03], p. 332) “a system composed of components with well-defined
interfaces between the components conforming to standard interface specifications”.
10 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

platform 1

platform 4
platform 2

platform 3
domain 1 domain 2

Figure 1.3: Example for an Independent Avionics Architecture


platform 1

platform 4
platform 2

platform 3

domain 1 domain 2

Figure 1.4: Example for a Federated Avionics Architecture

modules to take into account the different needs with respect to I/O and computing capabilities.
However, it shall emphasize the use of standardized platforms – aiming at repeated use of each
type. As a matter of fact, these figures do not represent real aircraft architectures since for many
different reasons hybrid variants of architecture models are used (e.g., non IMA modules in an
IMA architecture).
We observe that, conceptually, there are two separate evolution processes: The evolution of the
architecture models and the technological evolution. Typical avionics architecture models have
evolved from an architecture of almost completely independent systems via an architecture of dis-
tributed systems to a centralized architecture. At the same time, the platforms and the peripheral
equipment have been further developed resulting in enhanced processor capabilities and increased
memory capacities in combination with advances in operating systems and computer languages,
digital data busses and high-bandwidth communication links, major advances in microelectronics.
The resulting advanced peripheral equipment has also contributed to more distributed architectures
since more functionality (e.g., additionally transformation from analog signals to digital messages)
can be provided by these smart components.
These two development processes – advanced technology encouraging decentralization on the
1.3. AVIONICS ARCHITECTURE MODELS 11

IMA Module

IMA Module
IMA Module

domain 1 domain 2

Figure 1.5: Example for Integrated Modular Avionics

one hand, and conceptually more centralized architectures on the other hand – seem to contra-
dict5 : Instead of distributing the functions across more platforms (e.g., to take advantage of the
improved communication means), several systems share computing and memory resources of cen-
tralized modules (using an IMA architecture). To understand this evolution, we have to evaluate
the pros and cons of the technological development against consideration of functional, safety and
non-functional requirements. For the remainder of this section, we want to look at the different
architecture models from this aspect. This comparison is a preparation for the second part of this
thesis focusing on IMA platforms (Chap. 3) and IMA architectures (Chap. 4). It shall help to
substantiate the advances of IMA architectures but shall also show what new and sometimes criti-
cal factors have to be considered. Although a comparison of different generations of architecture
models applied to modern aircrafts which use current technology platforms is somehow artificial,
the pros and cons of each architecture type become clear. Moreover, new aircrafts do not necessar-
ily rely on newest architecture models (i.e., integrated modular avionics) for highly safety-critical
systems since the safety implications may outweigh the advantages.
Note that the given analysis of the system architectures focuses on the architectural aspects and
neither on the redundancy concept nor on the specific characteristics of the platforms or the appli-
cation software.6
In the beginning of this section, we have mentioned shortly the many different factors for evaluat-
ing the different architecture models. In detail, these are mostly related to the following safety and
non-functional requirements:

1. The type of platforms which are typically used for this architectural model and – in addition
– the type of platforms which can also be considered.

2. The type of communication links which are and can be used for this architectural model.

3. The provisions of the architecture for fault tolerance and avoidance of fault propagation.

4. The time, cost and responsibilities for development of the systems (including certification
actions) and system and multi-system integration.
5
On closer inspection, the conceptual differences between a more federated (i.e., more distributed) architecture and
the integrated avionics architecture (i.e., the more centralized one) are not significant as stressed in [Rus99], p. 3.
6
These aspects are discussed in more detail in the following sections (Sect. 1.4 and Sect. 1.5).
12 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

5. The maintenance costs and the maintainability (including the relation to the factor mean-
time-to-repair).

6. The upgradeability in case of technological advances.

7. The extensibility for future enhancements with respect to the increasing complexity of the
systems (including adaptation to new communication requirements and to additional com-
puting power).

8. The allocated space and the power consumption of the system’s platforms.

9. The environmental requirements (e.g. cooling, humidity) of the platforms for proper func-
tioning.

10. The weight for wiring and for the platforms themselves.

The evaluation of these criteria is compiled in Table 1.1, Table 1.2, Table 1.3, and Table 1.4. The
table representation allows, on the one hand, to compare the different architecture models for each
criterion (horizontal reading) or, on the other hand, to assess for a specific architecture model the
different criteria (vertical reading).
Evaluation Criteria Independent Avionics Federated Avionics Integrated Modular Avionics
Architecture Architecture
types of used / usable Typically bespoke special-to-purpose platforms are used. It is also possible to use Typically standardized special-to-purpose
platforms commercial-off-the-shelf (COTS) or standardized platforms, if they comply to the sys- platforms like IMA modules for safety-
(see Sect. 1.5 for general tem’s functional and safety requirements. critical functions, COTS platforms are us-
pros and cons) able for less critical functions, bespoke
special-to-purpose platforms may also be
used.
types of used / usable Generally all types of analog and digital communication links and data busses can be used. For historical reasons, the first generation
communication links of architecture models focused on analog communication links while nowadays fast digital communication links (with different
(see also Sect. 1.6) protocols) are available.
1.3. AVIONICS ARCHITECTURE MODELS

provisions for fault toler- Fault propagation from system to system The systems are executed on separate plat- Systems of different criticality may share
ance is impossible because the systems are not forms and thus fault propagation from sys- the computing and memory resources of
connected. Faulty interaction between tem to system is only possible by com- a single platform and thus fault propaga-
platform and sensor / actuator can be de- munication of data which can be detected tion has to be avoided by temporal and
tected and tolerated by the application (and then tolerated) by the application spatial partitioning mechanisms. In addi-
software. software. tion, fault propagation is possible by inter-
action via the communication links which
requires fault detection mechanisms on ap-
plication software level.

Hardware redundancy provides protection against random hardware faults. Software redundancy by means of diverse development
may reduce systematic software faults (see also Sect. 1.4).

Table 1.1: Evaluation of different architecture models (part 1)


13
14

Evaluation Criteria Independent Avionics Federated Avionics Integrated Modular Avionics


Architecture Architecture
time, cost and responsi- Bespoke platforms of the different systems are typically developed independently from IMA modules are developed by suppliers
bilities for development the others by the respective system supplier who is usually responsible for developing typically different from the system sup-
and certification (includ- the platform, the application software, and the sensors and actuators. When using COTS pliers (which provide the application soft-
ing verification and val- or standardized platforms, the platforms, the application software, and the peripheral ware and sensors / actuators). COTS or
idation) and system and equipment are typically developed by various commercial suppliers. standardized platforms are usually devel-
multi-system integration Synergetic effects between different system suppliers are unlikely, i.e., development, val- oped by commercial suppliers producing
idation and verification, and certification of the platforms have to be performed by each also for the non-avionics market.
supplier independently and thus cost or time cannot be saved for platform development. Testing and certifying each type of IMA
System integration is performed at the system supplier’s side; multi-system integration module (ideally only a few different types)
is the responsibility of the domain integrator or the aircraft manufacturer. is the responsibility of the platform sup-
plier and is performed for each type once
for the whole aircraft (although it might be
used for different systems and domains).
Application testing and certification is in-
dependent and performed by the system
supplier for its respective application soft-
ware.
System integration and multi-system inte-
gration are strongly coupled because ap-
plication software of different systems is
integrated on the same platform. The inte-
gration can only by carried out by the sys-
tem or domain integrator – usually the air-
craft manufacturer – in cooperation with
the application suppliers. Cost and time
for developing, maintaining, and configur-
ing the test rigs has thus become the re-
sponsibility of the aircraft manufacturer.
CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

Table 1.2: Evaluation of different architecture models (part 2)


Evaluation Criteria Independent Avionics Federated Avionics Integrated Modular Avionics
Architecture Architecture
maintainability If different specialized hardware is used for each system it has to be in stock for mainte- The use of standardized platforms and
nance at each maintenance station which generates enormous cost and may incur logistic additional on-board maintenance systems
problems since around 100 different platforms are hosted in an aircraft. simplifies maintenance. At each mainte-
nance station only very few different types
of platforms have to be in stock.
upgradeability in case of Upgrades of a platform or the application Upgrades may affect the respective sys- Upgrades of IMA modules shall have no
technological advances software only affect the respective system. tem and the interfaced systems. Re- effect on the application software and thus
Interference with other systems is impos- certification for the whole system and po- only IMA module testing and certification
sible (except for, e.g., electromagnetic in- tentially for some other systems has to be and hardware / software integration testing
terference of course). Usually certification performed. has to be performed.
of the whole system has to be repeated.
extensibility for future Enhancements may increase the complex- Enhancements may increase the complex- Additional system’s application software
1.3. AVIONICS ARCHITECTURE MODELS

enhancements ity of the application software and / or the ity of the application software and / or the might be added to a platform by config-
number of interfaced equipment. The number of interfaced equipment and / or uring an additional partition without af-
first may result in additional platforms the interfaces to other systems. The first fecting the spacial or temporal character-
leading to a more distributed architecture. may result in additional platforms lead- istics of other systems hosted by the plat-
Both can affect only the design of the ing to a more distributed architecture. The form (provided that appropriate spatial and
respective system’s architecture. Inter- others affect the intra-system and the inter- temporal spares have been planned in ad-
dependence only occurs with respect to system communication network resulting vance). No re-certification of the other
power consumption, size, weight, etc. Re- in additional wires and further space allo- systems is required.
certification for the whole system may be cation. Re-certification for the whole sys- Adding new platforms has the same affect
required. tem and the affected systems may be re- as for the other architectures: possible in-
If a new system is added a separate archi- quired. terference with respect to power consump-
tecture design is required and the new plat- If a new system is added the new platform, tion, size, weight, etc.
forms, sensors and actuators are installed sensors, actors and the new communica-
into the aircraft (interdependence with re- tion links have to be considered and thus
spect to power consumption, size, weight, affect all connected systems (interdepen-
etc. has to be considered). dence with respect to power consumption,
15

size, weight, etc. has to be considered).

Table 1.3: Evaluation of different architecture models (part 3)


16

Evaluation Criteria Independent Avionics Federated Avionics Integrated Modular Avionics


Architecture Architecture
size, power consumption Each system requires separate space Each system requires separate space Several systems share a common platform
and power for its platforms and sen- and power for its platforms and sen- which reduces the needs for space and
sors / actuators independent of the average sors / actuators independent of the average power consumption. IMA allows better
utilization of the processor or the sensors. utilization of the processor or the sensors. resource utilization and uses space and
Supply with normal and essential power Sharing sensor information may reduce power more economically.
is only necessary for highly safety-critical the overall number of sensors and thus the Supply with normal and essential power
systems. allocated space and the power consump- may be necessary for most platforms since
tion. the platform may host systems of different
Supply with normal and essential power criticality.
is only necessary for highly safety-critical
systems and those providing information
for more critical systems.
environmental require- Each platform contributes to the global warming of the respective compartment and thus needs air conditioning / cooling. When
ments of the platform comparing the architectures for systems of the same complexity, IMA needs a smaller number of platforms.

Permanent compliance with the environmental requirements is extremely important for Since IMA allows that systems of dif-
platforms executing highly safety-critical systems. ferent criticality share the same platform,
keeping the environmental requirements is
even more stringent to avoid the simulta-
neous loss of critical and uncritical sys-
tems.
weight of the system The weight depends on the number of platforms, thus when comparing the architectures for systems of the same complexity, IMA
needs less platforms and thus reduces the overall weight.

Point-to-point communication between Sharing of sensor information and (proba- Sharing of sensor information and (proba-
the platforms and the sensors / actuators bly) the use of advanced data busses allow bly) the use of advanced data busses allow
results in much wiring and thus much to reduce the wiring and thus the resulting to reduce the wiring and thus the result-
weight for the wiring itself. weight. ing weight. In addition, communication
between systems hosted on the same plat-
CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

form is performed via the backplane (fur-


ther reduction of wiring).

Table 1.4: Evaluation of different architecture models (part 4)


1.4. REDUNDANCY CONCEPTS 17

References
The evolution of the avionics architecture models described in this thesis follows mainly [Fil03],
[Rus99], and [SPC03]. Details about the different architecture models in general are also pro-
vided in [MS03] and – with a focus on integrated modular avionics architectures – in [LR03] and
[Mor01]. The characteristics of system architectures for all types of safety-critical systems are
also considered in [Sto96].

1.4 Redundancy Concepts

Redundancy is an important concept to achieve fault tolerance and thus to meet the associated
safety requirements. Each form of redundancy requires that additional elements are introduced
into the system design to tolerate failures of other elements. Four basic types of redundancy are
distinguished:

• Hardware redundancy means to use additional hardware. It is the most common method
of achieving fault tolerance against random hardware faults. Hardware redundancy can be
static, dynamic or hybrid. Static redundancy concepts mask faults by some form of voting
mechanism which compares the output of the parallel redundant components. Dynamic re-
dundancy approaches focus on fault detection (instead of fault masking) and provide standby
or backup systems which become active after detecting a hardware fault in the currently ac-
tive component. The reconfiguration causes a disruption of the system which is shorter when
the standby systems are running in parallel to the ‘active’ one (hot standby). Hybrid redun-
dancy combines the fault masking of static redundancy systems with the fault detection of
dynamic redundancy and thereby avoids transient faults which might be unacceptable.
The additional hardware used for redundancy can be duplicated identical components or
diverse components. The latter reduces the probability of systematic hardware design faults
(so-called common-mode faults) but requires independent development processes7 for the
different components which may be very time consuming and costly (depending on the type
of components used, diversity of COTS may be cheaper). Thus, development of diverse
hardware is only applied for highly critical systems.
From an architectural point of view, any form of hardware redundancy means that addi-
tional weight, increased power consumption, extra cooling, etc. has to be considered – and
weighted up against the expected benefits.8
A more detailed overview of these forms of hardware redundancy (including different voting
techniques and fault detection techniques) is provided in [Sto96], p. 131–144.

• Software redundancy means executing additional software to detect or tolerate faults.


Since execution of duplicated (i.e., identical) software modules only reduces the likelihood
of transient faults but does not protect against software design faults, software redundancy
is usually associated with separate design and development of the additional software com-
ponent. Again, the resulting costs are only acceptable for very critical systems.
The execution of the additional software does not necessarily mean that additional hardware
has to be added. Nevertheless, the additional computing and memory needs have to be con-
sidered and often result in additional hardware components.
Software fault tolerance techniques are discussed in more detail in [Sto96], p. 144–148.
7
Note that each such development process is based on the same system specification. As a consequence, errors in
these specifications will affect each diversely developed design.
8
For the Airbus A380, the weight of the aircraft and the power consumption are major factors in guaranteeing the
advertised range and kerosene consumption per flight mile to the prospective customers.
18 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

• Information redundancy means providing additional information to detect or tolerate


faults. Examples are parity bits, checksums, error detection or correction codes. Another
form is the use of algorithms to transform data and create multiple copies.
Information redundancy can be implemented using hardware or software techniques.
• Temporal (time) redundancy means to spend time in addition to that required for the non-
redundant execution. In particular, this can include to repeat calculations and then compare
the results to detect transient faults.
Hardware and software techniques can be used to implement temporal redundancy.

Summarizing, each form of redundancy allows to tolerate or detect specific faults but may involve
high costs for development and verification (especially when requiring dissimilar components) and
during operation (in particular considering weight, power consumption). For saving development
costs, it is preferred to tolerate faults, particularly random faults, on HW level using non-diverse
additional hardware, but apply extensively fault avoidance and fault removal methods at software
level to avoid and detect software design and implementation errors. Development or operational
costs are less important matters for most (highly) safety-critical systems. As a consequence, these
use mixtures of the above described redundancy techniques to provide fault tolerance against a
range of possible faults. Some examples are listed in the following:

• Hardware redundancy with duplicated platforms and duplicated wiring to tolerate and detect
hardware faults. For example, the IMA modules and the AFDX network for inter-module
communication are set up redundantly within the Airbus A380. Also the Fire and Smoke
Detection System in the Airbus A380 is designed as a hot-standby hardware redundant
system. Usually, the redundant systems are also physically distributed on-board the aircraft
to avoid total loss of the redundant components in case of fire or water in one of the avionics
compartments.
• Hardware redundancy with duplicated input sources – either by using several identical
sensors or by using diverse sensors – to protect against single-point failures (see [Sto96],
p. 132). For example, it is common practice to have more than one fire and smoke sensor in
each compartment and mechanisms to deal with diverse status messages of sensors located
in the same compartment.
• Software redundancy – in particular in the form of N-version programming – is applied
for highly critical applications to achieve software fault tolerance against software design
(and implementation) errors. Such an application is the primary flight control system in the
Airbus A330/340 ([Sto96], p. 145).
• Combinations of hardware and software redundancy are used to combine the benefits of
both concepts. A prominent example is described in [Sto96], p. 152: the computer system
of the NASA space shuttle where redundant COTS computers with hardware fault detection
mechanisms have been combined with 2-version programming of the flight control system.
• Information that is critical for continuing safe flight may be duplicated using information
redundancy techniques. For example, detected smoke or fire in the Airbus A380 is com-
municated to the cockpit by a specific discrete signal as well as via AFDX (the latter also
allows to communicate additional information). This is also a form of hardware redundancy
(redundant hardware for the communication link) although different communication means
are used.

References
[Sto96] and [Sto99] elaborate in detail on the different redundancy concepts. [AIR5428] addresses
redundancy considerations in avionics systems, particularly integrated avionics systems.
1.5. CATEGORIZATION OF PLATFORMS 19

1.5 Categorization of Platforms

In this thesis, the term platform refers to computer hardware and its operating system (OS) soft-
ware and drivers. A platform can be used to execute different pieces of application software. This
combination of application software and a specific platform is often called a controller. The com-
ponents of a platform – on one hand the hardware and, on other hand, the OS and the drivers – can
be either standardized or unstandardized and either special-to-purpose or commercial off-the-shelf
(COTS). These terms are defined as follows:

• Standardized means that a reference specification exists which describes the hardware char-
acteristics or the operating system API. Standards are prepared by a specific working group
and released by a standardization authority, e.g., ARINC, IEEE, RTCA. Standards can be
implemented by different suppliers.
Unstandardized means that the component has not been developed according to such a stan-
dard. Many so-called standard operating systems belong to this group, e.g., Linux, Unix,
Windows.9

• Commercial-off-the-shelf (COTS) is hardware or software which is readily available at the


market and has not been developed for a particular application area.
Special-to-purpose or bespoke components on the other hand are developed for a specific
application (tailored development). The application area (i.e., the purpose) can be a spe-
cific aircraft type (e.g., a specific fire and smoke detector only to be applied in the Airbus
A380), execution of real-time applications (e.g., a real-time operating systems (RTOS)) or
systems with specific requirements (e.g., avionics systems and automobile systems with
specific safety and environmental requirements, industrial PCs with specific environmental
requirements).

In the previous sections – in particular in Sect. 1.3 – the following types of platforms and equip-
ment have been mentioned:

• COTS platforms,

• special-to-purpose platforms,

• IMA modules (i.e., standardized special-to-purpose platforms), and

• peripheral components, i.e., sensors, actuators, so-called smart components.

In the following, we will discuss these different platform types, provide examples and evaluate the
respective characteristics. The evaluation shall consider the following criteria:

• development of the platform (time and costs);

• verification, validation and certification (including answering the question who is responsi-
ble for these tasks);

• consideration of fault avoidance and fault removal methods;

• consideration of functional requirements;

• consideration of reliability, availability, system integrity, data integrity, maintainability;


9
Although different implementations exist for Unix operating systems, they are not all alike and in particular do
not implement a common reference specification which has been agreed by some sort of committee. POSIX provides
specifications for parts of the operating system but does not comprise all parts of the OS.
20 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

• conformance to environmental aspects (i.e., to temperature, shock, vibration, humidity, wa-


ter penetration, electromagnetic compatibility, etc.);

• conformance to size and weight restrictions for hardware components, and memory restric-
tions for software components; and

• conformance to interface restrictions.

1.5.1 COTS Platforms

COTS platforms are composed of a commercially available hardware component and an oper-
ating system (e.g., Unix, Linux, Windows, real-time Linux). In general, COTS components are
developed for the mass market without considering the particular requirements of real-time safety-
critical systems. This means on one hand that COTS components are relatively inexpensive and
typically available on demand which reduces the time and cost risks with respect to the devel-
opment of the component. On the other hand, COTS components are typically not developed
following a development process needed for fault avoidance and are further not prepared for veri-
fication, validation and certification as requested by the respective avionics standards. In particular,
this information is often regarded as proprietary by the company developing the component. As
a consequence, verification and certification remains with the component supplier. In addition,
properties like reliability, availability, system integrity, data integrity and maintainability are often
not considered adequately for the use in avionics. In particular, maintainability raises many im-
portant questions with respect to longevity and stability of COTS components: how long will the
hardware be available unchanged for maintenance?, how is it possible to control the change of a
COTS component?, will the component be available for the typical life time of an aircraft (i.e., for
20–50 years)?.
Considering the functional requirements, COTS components are not developed to fulfill the spe-
cific functional requirements of the given system and consequently have less or more features,
some of which may surprise and may not even been described in the respective specification doc-
uments. In particular, unstandardized components have this problem.
Also, COTS hardware may not be designed to cope with the environmental demands of avionics
systems which impacts the reliability and availability of the component. For example, the temper-
ature ranges, shock and vibration, or electromagnetic compatibility (EMC) that a desktop PC has
to cope with are much less demanding than the environment on board an airplane.
Furthermore, COTS components have been developed without any particular restrictions regarding
size and weight of the hardware component or memory for the software component. For avionics,
aerospace, automobile and telecommunication, these factors may be crucial.
At last, the interfaces needed for avionics may not be available in COTS components or the con-
nector may not comply with the avionics standard (e.g., ARINC 600).

Examples for COTS hardware components are (unstandardized) standard PCs or PC-based
components, standardized PC-based components like VME or PC/104, or programmable logic
controllers (PLCs). In particular, the standardized components are meant for deployment in avion-
ics or aerospace (see [Coo03], p. 12, [Sto96], p. 253–268): they are robust, wide-temperature-
range boards and more reliable and dependable than other COTS. For PLCs, the TÜV Germany
offers a certification service for hardware and OS (i.e., the firmware) ([Sto96], p. 255) based on
details provided by the vendor.
Although COTS hardware components have the disadvantages listed above, they have been used,
e.g., in the space shuttle ([Sto96], p. 152), and US military aircrafts ([Tal98], p. 50). COTS hard-
ware is also used on board the Airbus A380 for less critical systems. An example for the relatively
1.5. CATEGORIZATION OF PLATFORMS 21

short life cycle of COTS components compared to that of an aircraft system is described in [Fil03]
(p. 4) showing the production of the chosen processor was stopped prior to first operational use of
the aircraft.
In general, COTS hardware components will be mainly used at device level, e.g., processing ele-
ments, memories, and less at board level. For example, the PowerPC processor is widely used in
safety-critical embedded systems.

Examples of COTS operating system components. For standard PCs and VME, operating
systems like Linux, Unix, Windows and also more special-to-purpose real-time operating systems
are available. The latter includes – but is not limited to – RTLinux (by Finite State Machine
Labs, Inc.), LynxOS (by LynuxWorks), VxWorks (by Wind River), VRTX (by Mentor Graphics),
CsLEOS RTOS (by BAE SYSTEMS Controls), INTEGRITY-178B (by Green Hills Software),
and Valid-653 (by Validated Software Corporation). The latter three also support the ARINC 653-1
API as used for IMA modules. For PLCs, the operating system kernel is provided as firmware.
Application examples for PLCs in safety-critical systems are given in [Sto96] (p. 261–267).
VxWorks is used in the Mars exploration rovers and several other spacecrafts and intended to
be used in Boeing’s 7E7. VRTX has been used for the Hubble space telescope.

1.5.2 Special-to-purpose Platforms

Special-to-purpose or bespoke platforms have been developed and optimized for the requirements
and needs of a particular system. This means that the component (either hardware or operating
system) contains only the required functional features as documented in the related specification
and design documents. Further, it is possible to define exactly which standards have to be adhered
to for the development and verification and validation process which simplifies the certification
of the component (compared to the difficulties when certifying COTS components). The tailored
development also allows to consider and conform to environmental aspects, size and weight re-
strictions, interface requirements, etc.
Nevertheless, consideration of all these aspects is time-consuming and costly and the high risk
for not developing the component in time cannot be ignored and may lead to costly delays in the
overall aircraft development.
Furthermore, the airline’s dependence on the platform supplier is significant since due to the lack
of standardization it is not possible to get the platform from another supplier. Appropriate contracts
can contain this problem.

Examples for special-to-purpose platforms are manifold since in the past – using federated ar-
chitectures – this type of platform has been preferred. The CIDS board in most of the newer Airbus
airplanes is a bespoke platform.

1.5.3 IMA Modules

Integrated Modular Avionics platforms are standardized special-to-purpose platforms which com-
ply with the respective ARINC standards: The IMA module’s connectors and hardware dimen-
sions comply with ARINC 600, it provides communication interfaces according to ARINC 664,
ARINC 429, or ARINC 629, and the operating system API to be used by the application software
complies with ARINC 653-1. However, other hardware characteristics (i.e., number of processors,
memory size, etc.) are not standardized since technological progress is assumed to be faster than
the standardization process and what seem reasonable today is probably outdated tomorrow.
22 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

IMA modules combine the advantages of COTS platforms and unstandardized bespoke platforms:
Different suppliers can offer certified IMA modules complying to the respective standards which
have been developed according to the requirements of the respective standards. For example,
compliance of the operating system with ARINC 653-1 can be shown by the test suite defined in
ARINC 653-3. Furthermore, the IMA approach with its clearly specified API allows concurrent
development of the platforms and the applications to be running on it.
Avionic data busses like ARINC 664, ARINC 429 and ARINC 629 are discussed in the following
section (Sect. 1.6). IMA platforms and their operating system API are considered in more detail
in Chap. 3. Testing of IMA modules is investigated in Chap. 5 and detailed by a case study in part
3 of this thesis.

Examples. Different generations of IMA modules have been used so far (see [MS03], p. 334–
336): the first IMA modules applied in the Boeing 777 were developed before the first version of
the ARINC standards were released. As a consequence, the modules followed a closed architecture
and were obtained from a single supplier. The second generation of IMA modules was partially
standardized and deployed in the Boeing 777 and Honeywell EPIC. The current generation of
IMA modules complies with the aforementioned standards and is used in the Airbus A380.

1.5.4 Peripheral Equipment

Peripheral equipment comprises sensors and actuators which are connected to the data bus by a
data concentrator. Some of them – so-called smart components – can have a degree of intelligence
and interface directly to the digital bus. Peripheral equipment in general can be commercial-off-
the-shelf, special-to-purpose or a combination of both and thus combine the pros and cons as
described above. In the following, we will briefly discuss the advantages of smart peripherals
since the trend goes from conventional actuators and sensors to their smart successors. A more
detailed discussion of peripheral equipment, however, is outside the scope of this thesis.

Smart Peripherals are system peripheral devices which provide considerable more function-
ality than traditional ones and are connected to the digital data busses. Therefore, they are also
called remote data concentrators (RDCs). The advantages of smart components in contrast to con-
ventional ones are manifold (see also [Moo01], p. 33-8): Smart components provide considerably
more functionality, but by using advanced microcircuits they occupy only almost the same space
as conventional ones. Further, the interface to the peripheral’s environment is simplified because
the data are processed at the ‘point of action’ which allows to aggregate information and thus re-
duce the communication flow between peripheral equipment and controller. This pre-processing
of the smart components includes conversion from analog data to digital data which makes the
communication less error prone. Fault localization is also simplified since the smart component
can use on-the-fly built-in fault detection mechanisms. Further, smart components support ar-
chitectural flexibility because the data is available everywhere in the aircraft via the data busses.
The installation complexity can additionally be reduced by using the existing data bus and its re-
spective (probably standardized) connectors (instead of direct wiring between the peripheral and
controller). Thereby, the smart components contribute significantly to the reduction of wiring and
weight. Additionally, the interface of the smart components can be standardized without posing
restrictions on the internal technology of the peripheral. But one should also take into account
that this leads to more complex components which probably increases the cost and time effort for
development, verification and certification. Furthermore, the resulting architecture depends on the
reliability of the data bus connecting several peripherals with the controller – loss of one data bus
means loss of all connected peripherals. This risk can be reduced by using redundant busses (with
all consequences on wiring and weight).
1.5. CATEGORIZATION OF PLATFORMS 23

Examples. Smart peripherals are especially used in most systems where sensors and actuators
are distributed over large parts of the aircraft: doors and slides management, fuel gauging system,
flight attendant panels, etc. For example, the doors and slides management system as described
in [Diehl04] consists of a central management controller and distributed smart peripherals which
are located at the passenger doors, emergency exits, cargo doors, bulk cargo doors, avionics bay
hatches and mobile crew rest hatches. The central management controller (which is running as
an application on an IMA module) is connected to the smart components via a triple redundant
CAN bus. In the fuel gauging system described in [Moo01], p. 33-9, a central gauging controller
is located in the avionics bay and connected to smart fuel gauging modules (which are in fact
integral tank-wall connectors) via ARINC 629 or ARINC 429.

1.5.5 Operating System Requirements


In the previous sections, we have discussed (real-time) operating systems in general without con-
sidering the specific requirements for application in the avionics domain. In accordance with
[Kro04] and [Rus99], operating systems to be used in avionics systems have to consider the fol-
lowing criteria:

• Real-time capabilities shall ensure predictable timing behavior by providing real-time


clocks and timers for the scheduler and the application software.
• Partitioning shall provide protection against fault propagation from one function to another.
This mechanism is necessary for separation of functions (e.g., on standard platforms) as
well as for multilevel criticality isolation (e.g., on IMA platforms).
– Time partitioning considers deterministic scheduling of different partitions and deter-
ministic scheduling of different threads within one partition.
– Space partitioning refers to memory management and protection which includes static
allocation of code, maximum stack sizes, fixed sizes and locations for memory heap.
Its memory protection includes memory access rights (e.g., to treat code different from
stack area). Memory protection can also be supported by the processor hardware.
• Communication mechanisms shall allow data flow between partitions and communication
with external platforms or peripheral equipment.
• Health monitoring shall detect illegal access to memory, ports, and the computing resource
by working as a watch dog in the time and space domain. In case of errors, configured
actions can be taken.
• Configurability shall allow to define for the RTOS the scheduling of the partitions, the mem-
ory allocation for each partition, and the handling of specific errors, among others.

The selection of an appropriate operating system – whether COTS or special-to-purpose – for a


given hardware platform is important for the overall characteristics of the platform. Further, it
determines the possibility to verify and certify the platform in conformance with the applicable
standards (e.g., DO178B). One factor which additionally has to be considered is the processor
of the hardware platform: For many complex embedded computers systems of today a PowerPC
processor is used whose memory management unit (MMU) can support the implementation of the
memory protection mechanism.
Different approaches for partition-supporting RTOS are listed in [Kro04] (p. 13):

• The POSIX specification defines the basic set of services to implement portable applications
which includes in the current version real-time capabilities, threads, and networking. POSIX
provides C and Ada bindings.
24 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

• The ARINC 653 specification defines an API for implementing avionics applications to be
executed concurrently on the same platform. In addition to the API, a model is provided
which defines the general behavior of RTOSs conforming to ARINC 653. ARINC 653
defines C and Ada language bindings.

• The Ravenscar profile is an Ada profile which restricts the set of available Ada services to
those which are necessary to implement high-integrity efficient real-time systems without
endangering the overall safety. The Ravenscar profile is a de-facto standard which has been
widely accepted – also by the ISO standards body. Further information about the Ravenscar
profile can be found in [Bur].

For the rest of this thesis, we will focus exclusively on operating systems conforming to ARINC
653. ARINC 653 has been inspired by the ideas of POSIX though ARINC 653 and POSIX are
not compatible, i.e., applications are not portable without changes. Also, the ARINC 653 Ada
binding and the Ravenscar profile are incompatible. Nevertheless, portability between POSIX and
ARINC 653 C binding or between Ravenscar profile and ARINC 653 Ada binding, respectively,
is not necessary for avionics applications since they are typically developed based on the specific
requirements of an aircraft and are not developed to make them available on the market.
ARINC 653 and the API services to be provided by such operating systems, the configuration as-
pects and the approach for developing application software for ARINC 653 platforms are provided
in detail in Chap. 3.

References
COTS platforms and their usage in avionics is discussed in [Sto96], [Tal98], [Coo03], among oth-
ers. Application examples for a COTS real-time operating system are addressed in [Avi04]. The
hardware and software of IMA platforms are described, for example, in [VICTORIA], [MS03],
[ARINC653P1-2], and [ARINC653P3]. Application examples of remote data concentrators in
avionics systems can be found in [AV04f]. [Rus99] and [Kro04] address the requirements of
operating systems to be used in avionics.

1.6 Categorization of Aircraft Networking Technology

The network on board an aircraft connects the controllers with their peripheral devices and also
enables inter-controller communication. For federated architectures, the network can be divided
into two layers which use different networking technologies: The upper layer in the networking
hierarchy refers to controller-to-controller communication networks whereas the lower layer con-
siders the communication network between controller and peripherals. Typically, there exists one
lower layer network per system since the sensor information is not shared directly (but the sys-
tem’s main controller may provide the information in an abstracted way). In integrated modular
architectures, the networking hierarchy is partially dissolved. Different tasks of one system as
well as different systems can be co-located on the same IMA module, i.e., intra-system and inter-
system communication cannot be distinguished if the internal communication means of an IMA
module are used.
This mixing of networking layers introduces new authentication, performance, safety, and security
risks. When choosing an appropriate networking technology to be used for an IMA architecture,
one has to consider both the architectural level and the platform level. With respect to the net-
working architecture, it is recommended to divide the upper layer into different networks which
are connected and separated by appropriate means. Considering the platform level, it has to be
1.6. CATEGORIZATION OF AIRCRAFT NETWORKING TECHNOLOGY 25

shown that communication of one partition of an IMA module10 does not affect the configured
characteristics of communication links belonging to the other partitions of the same IMA module.
The architectural considerations will be discussed briefly in the following. Verification of platform
characteristics is addressed in detail in Chap. 5.
Standards like [ARINC664P1-1] recommend that the aircraft computing network is divided into
four sub-networks. These sub-networks are called aircraft domains in [ARINC664P1-1]. This
definition of the term aircraft domain differs slightly from the term domain used in Sect. 1.1 where
a domain was the functional grouping of systems. Aircraft domains in contrast are supersets of
networks with the same requirements for performance, safety and security. In [ARINC664P1-1]
and [ARINC664P5], it is suggested to group the aircraft computing network into four aircraft
domains – the aircraft control domain, the airline information services domain, the passenger
information and entertainment services domain, and the passenger owned devices domain – which
may be further divided into sub-domains. Figure 1.6 depicts the suggested grouping. Some aircraft
domains may provide services to the other domains which requires appropriate mechanisms at the
borders of each domain to ensure the required security level of each aircraft domain. Note that in
Fig. 1.6 the level of criticality decreases from left to right while the level of protection mechanisms
needed to achieve the required safety depends only on the characteristics of each domain.

Aircraft Airline Passenger Passenger


Control Information Information Owned
Domain Services and Devices
Domain Entertainment Domain
Services
Flight and Adminstrative Domain
Embedded Sub-Domain
Control System
Sub-Domain

Cabin Core Passenger


Sub-Domain Support
Sub-Domain

Figure 1.6: Grouping of the aircraft computing network into four aircraft domains

Aircraft domains. The aircraft control domain is divided into two sub-domains: the flight and
embedded control system sub-domain and the cabin core sub-domain. The flight and embedded
control system sub-domain comprises the systems which control the aircraft from the flight deck.
This aircraft domain is related to the flight control domain, the engine domain, the cockpit domain,
the utilities domain and the energy domain (all described in Sect. 1.1). The cabin core sub-domain
subsumes the systems for environmental control, smoke detection and slides and doors manage-
ment. It is related to the cabin domain in Sect. 1.1.
The airline information services domain can be subdivided into two sub-domains: the administra-
tive sub-domain and the passenger support sub-domain. The administrative sub-domain provides
operational and airline administrative information to the flight deck and the cabin and maintenance
10
The term partition refers to one task of an IMA module. Two partitions on the same IMA module can either
belong to the same system (in this context usually called application) or to different systems. The terms partition and
application are defined in Chap. 3.
26 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

services. It is related to the OIS domain in Sect. 1.1. The passenger support sub-domain provides
information to support the passengers. It is related to the OIS domain and the PCES domain.
The passenger information and entertainment services domain provides the in-flight entertainment
(i.e., video, audio, gaming), passenger flight information, and access to the Intranet and Internet us-
ing built-in terminals including related services like Voice over IP, Short Message Service (SMS),
and Email. It is related to the PCES domain.
The passenger owned devices domain is a network of those devices that passengers may bring on
board to connect to the passenger information and entertainment services or to one another.
These networks and sub-networks differ with respect to the platform types connected by the net-
work, the performance requirements, the access rights, and the other configuration, security and
certification characteristics. The networks in the aircraft control domain are static networks which
connect safety-critical systems and thus failure to meet the real-time or availability requirements
may have catastrophic effects. The requirements of the airline information services domain and
the passenger information and entertainment services domain are less stringent and the effects
of potential failures less critical. Nevertheless, it is important that these networks are protected
against viruses, worms, denial of service attacks, etc. which may come from malicious passenger
owned devices.
In this thesis, the focus is on systems, platforms and networking technology applied in the aircraft
control domain. The above division into aircraft domains is given to provide a complete overview
of the networks aboard an aircraft and the many different requirements and characteristics to be
considered when designing the aircraft network and specifying the requirements documents. For
a detailed and comprehensive comparison of the network characteristics the reader is referred to
[ARINC664P5], in particular Appendix I.
In the following, we will focus on networking technology used where real-time communica-
tion with bounded jitter and latency, high availability and integrity of the network is required
but the necessary communication bandwidth is low, and the network configuration is static, i.e.,
all networking nodes are known at configuration time. We will consider both networking tech-
nology for controller-to-controller and for controller-to / from-peripheral communication. Inter-
controller networks typically conform to MIL-STD-1553B, ARINC 429, ARINC 629 or ARINC
664 / AFDX, but proprietary solutions are also possible. For communication between controllers
and peripheral devices, analog and digital signals, commercial RS232 and RS422, digital data
busses like ARINC 429, ARINC 629, Controller Area Network (CAN), as well as a variety of
proprietary solutions are used. For the less critical parts, Ethernet-based application-specific pro-
tocols may also be used, e.g., for communication with intelligent graphical user interfaces in the
cabin. As discussed in previous sections (e.g., Sect. 1.3), digital bus solutions are preferred to
dedicated wires carrying analog or digital signals in order to reduce the amount of wiring needed
to connect a controller with many peripheral devices. In the next sections, the main characteris-
tics of ARINC 429, ARINC 629, ARINC 664 / AFDX, and CAN are discussed along with some
examples. MIL-STD-1553B is a military standard and further consideration is outside the scope
of this thesis since it is typically not applied in civil aircrafts.

1.6.1 ARINC 429

The ARINC 429 digital data bus ([ARINC429]) became the first standard data bus to be applied in
civil aircrafts, e.g., in Airbus A300/310, A318 and A340-500/600, and Boeing 757 and 767. Be-
fore the development of ARINC 629 and ARINC 664 / AFDX, it was the most widely used means
for communication between controllers or controllers and smart peripheral devices (as noted in
Sect. 1.5.4). ARINC 429 is intended for exchanging of very small payload units (24 bits per 32-
bit-package) at a data rate of 100 kbit/s. The payload is identified by the 8 Bit label contained
in each package. Many fixed labels and thus payload formats are defined in the standard which
1.6. CATEGORIZATION OF AIRCRAFT NETWORKING TECHNOLOGY 27

allows that each receiver can access the payload without additional coordination efforts. Typi-
cally, the payload contains discrete state information and switching commands. For example, one
label is specified to represent the state of the fasten-seat-belt and no-smoking signs, others carry
temperature control commands for the air conditioning system.
The ARINC 429 data bus operates in a single-source-to-multiple-sinks unidirectional mode so that
each sender can transmit a message to different receivers but for replying to the sender separate
data busses are required (one for each sender). Thus, collision avoidance is inherent.
Security issues and access rights have not been considered in the ARINC 429 standard because the
data bus is only intended for static networks of mechanically integrated controllers and peripheral
equipment.
Summarizing, the pros and cons of ARINC 429 are:

+ standardized labels

+ digital data bus helps to reduce the wiring needed to connect different controllers

+ single-source-to-multiple-sinks mode means that it is well suited for inter-controller and


controller-to-actuator communication that often distributes one information to many re-
ceivers

– single-source-to-multiple-sinks mode also means that it is not suited for sensor-to-controller


communication because the wiring reduction seems to be negligible (although only one data
bus is needed to transmit the status information to redundant controllers)

– single-source data bus means that each piece of equipment needs as many input ports as the
number of sources it expects to receive data from

± unidirectional mode determines the roles of sender and receivers but can result in additional
data busses for acknowledgments or replies

+ small ARINC data packages support guaranteed real-time behavior

– small payload may lead to low throughput, i.e., ARINC 429 cannot be used for audio or
video transmission

± not for dynamic open networks but very reliable for static networks

1.6.2 ARINC 629

ARINC 629 was developed to overcome the drawbacks of ARINC 429 – in particular with respect
to the number of senders and receivers per data bus and the data rate. The development was driven
by Boeing who invented the Digital Autonomous Terminal Access Data Communication (DATAC)
data bus that has been used in the 777 only. Nevertheless, it later became an ARINC standard.
ARINC 629 operates in multiple-sources-to-multiple-sinks mode which allows much more free-
dom in the exchange of data between communication nodes and thus reduces the required amount
of wiring. The data bus operates at 2 Mbit/s. The protocol used by ARINC 629 follows a time-
based collision-avoidance concept in which each communication node is allocated a particular
time slot to access the bus and transmit data on to the bus. Bus access control is distributed be-
tween the nodes which autonomously decide when the appropriate time slot is available through
the use of several control timers embedded in the bus interfaces.
The advantages and disadvantages of ARINC 629 are:

+ multiple transmitters are allowed which helps to further reduce wiring


28 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

+ multiple-sources-to-multiple-sinks means that a communication node can receive and trans-


mit via a single communication port (addressing redundancy or other architectural consid-
erations may lead to additional data busses)

+ multiple-sources-to-multiple-sinks mode means that it is well suited for communication on


upper and lower layer of the networking hierarchy

+ high data rate allows higher throughput than is achievable with ARINC 429 networks, i.e.,
ARINC 629 can generally also be used for audio and (low-quality) video communication

- throughput is not sufficient to allow parallel audio and video communication with acceptable
quality

1.6.3 ARINC 664 and AFDX

ARINC 664 is a fast networking data bus based on commercial, state-of-the-art Ethernet stan-
dards from IEEE and IETF (for details see introduction section of [ARINC664P3-1]. The aim of
ARINC 664 is to provide secure and reliable communications for the exchange of both critical and
non-critical data. The standard ARINC 664 is specified in seven separate document parts (see ref-
erences list at the end of the chapter). Part 1 to 5 of the standard describe the general concepts and
implementation options for an aircraft data network but give room for many implementation de-
cisions with respect to operational mode (e.g., half- or full-duplex operation), used protocols and
services, address structures, and network interconnection services. One variant for a deterministic
networks is defined in part 7 ([ARINC664P7])– the so-called Avionics Full Duplex Switched Eth-
ernet (AFDX). This variant is used for the Airbus A380 where it replaces the ARINC 429 network
for most inter-controller communication. For the rest of this thesis, we will consider AFDX only.
ARINC 664 – and thus also AFDX – are based on standard Ethernet which is basically a
non-deterministic transmission medium without guaranteed bandwidth since collision cannot be
avoided if hubs are used for connecting the network nodes and switches may need to buffer data.
To achieve a deterministic behavior, the point-to-point connectivity used for ARINC 429 data
busses is emulated using a star topology switched Ethernet. In such a topology, collisions can
never occur on the wire, but may be resolved within the switches within bounded time intervals.
This is achieved by controlling latency and jitter of each so-called Virtual Link (VL) resulting in a
bounded bandwidth and bounded frame delivery interval for each VL. This results in a calculable
maximum latency in the network rather than a probabilistic latency depending on the amount of
traffic. Nevertheless, this solution forbids the use of transport layer protocols which require re-
transmission of lost messages (e.g., TCP) since occasional loss of message cannot be determined
in advance and thus cannot be included in the bandwidth calculation of a VL. In general, occa-
sional loss can be tolerable if state information is transferred repeatedly. Otherwise appropriate
protocols have to be defined at application layer to overcome this limitation, e.g., by adding a
sequence number to each message.11 In avionics applications, timely transmission of messages
is much more important than reliable data delivery. For many applications using conventional
networks, usually the opposite holds and short delays are acceptable. Note that the likelihood of
packet loss in an AFDX network is very low owing to the topology and network characteristics
and expected only in case of rare bit errors (which can be detected using CRC mechanisms). Fault
tolerance and availability of the network can be provided by redundant links via physically sepa-
rated networks (and thus different wires). Duplicated messages are then checked for integrity and
filtered in the receiver redundancy management unit.
11
Note that application layer means on top of ARINC 653 ports and thus on top of AFDX ports is outside the scope
of this thesis.
1.6. CATEGORIZATION OF AIRCRAFT NETWORKING TECHNOLOGY 29

Data flow can be further isolated by providing a cascaded star topology, i.e., switched networks
connected by a switch or router. This also provides the necessary scalability for large networks
which may be needed when AFDX is used for controller-to / from-peripheral communication.
The switches used within AFDX networks are statically configured by configuration tables as are
the VLs of the communicating nodes (which are called end systems within the context of ARINC
664). This is necessary to achieve deterministic performance and to avoid latencies when gener-
ating new entries in dynamic routing tables. Unlike in open world networks, all communication
links and end systems are pre-defined and deterministic in avionics systems.
Since ARINC 664 / AFDX is based on Ethernet technology, it offers higher bandwidth than
ARINC 429 and ARINC 629. Additionally, the length of logical frames is up to 8 KBytes which
allows complex payloads containing structured data, text, audio and video streams. Thus, it is also
well-suited for application in the airline information services domain and passenger information
and entertainment services domain. Connection to these domains and to the passenger owned de-
vices domain is easy to realize using appropriate switching and firewall techniques since the basic
means are the same (namely Ethernet, UDP, etc.).
The payload of AFDX messages is not standardized in the ARINC 664 documents, i.e., labels like
the ARINC 429 labels have not yet been defined. Nevertheless, AFDX messages can be used to
transport ARINC 429 labels – either by sending a single ARINC 429 label per AFDX message
(single label message format) or by combining several ARINC 429 labels in one AFDX mes-
sage (multiple label message format). Corresponding examples are provided in [ARINC664P7d],
p. 126–129. In addition, it is possible to group primitive data types (i.e., integer, float, boolean,
etc.) together in a message using a sequence of Functional Data Sets (FDSs). Figure 1.7 de-
picts the message structure of a UDP packet containing one or more FDSs (figure according to
[ARINC664P7d], p. 86). Each functional data set consists of two fields: A 4-byte Functional

Status Status Status Status Data Data Data


Byte 1 Byte 2 Byte 3 Byte 4 Primitive 1 Primitive 2 Primitive 3 ...

Functional Status Set Data Set 1 Data Set 2 Data Set 3 Data Set 4
(FSS) (DS 1) (DS 2) (DS 3) (DS 4)

Functional Data Set 1 Functional Data Set 2


(FDS 1) (FDS 2) ...

Reserved sequence of Functional Data Sets (one or more)

UDP Header UDP Payload

Figure 1.7: Sequence of functional data sets in a UDP packet

Status Set (FSS) which comprises in each byte the health and status of one of the following four
Data Sets (DSs). The length of the sequence of FDSs is only limited by the payload of the un-
derlying transport mechanism (e.g., by the UDP payload size). Each DS can comprise many data
primitives whose health and status is represented by one common field in the corresponding FSS.
30 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

This means that if one data primitive of a DS is invalid, the entire DS is marked invalid. As a
consequence, a DS usually groups data which originates from the same source to avoid this form
of “fault propagation” which may occur when grouping data from different sources. For example,
if a sensor sends different readings all at the same rate to its corresponding controller which has
previously be done by sending ARINC 429 message with different labels, all information can be
sent by one AFDX message but each piece of information is contained in a different DS.
ARINC 664 / AFDX also allows multicasting, i.e., multiple sinks for one message. This is pos-
sible by using MAC multicast addresses (like in standard Ethernet) which provide routing and
duplication of the messages as required.
The API for the application layer of AFDX end system is defined in ARINC 653 which is de-
scribed in detail in Chap. 3. The basic idea with respect to inter-module communication is that
ARINC 653 provides two types of communication ports: queuing ports for transmission of indi-
vidual, sequential messages and commands and sampling ports for state information which shall
be available for repeated reading until reception of newer values. Both types of ports shall be us-
able with AFDX. This requires an AFDX layer on top of the OSI transport layer since for receive
ports queuing or sampling port functionality is not provided by UDP ports.
The pros and cons of AFDX can be summarized as follows:

+ protocols and basic transmission technology based on open world technology and protocols

+ well-suited for all types of network domains since the maximum frame length is 8 KBytes

+ high data rate of 100 Mbit/s for the data bus and guaranteed bandwidth and latency per VL
(if a legal configuration is used)

– switches and end systems have to be configured to achieve deterministic performance, con-
sistency and correctness (according to the available and required bandwidth) of configura-
tion tables has to be analyzed and adds additional verification tasks which are not necessary
for ARINC 429 and ARINC 629 networks

+ use of COTS components for switches and end system technology possible (if complying to
the specific requirements of AFDX), helps reducing development and purchase costs

+ multiple transmitters are inherently allowed

+ multiple receivers are possible using the means of the link layer multicast

– format and content of payloads is not standardized by ARINC 664 and has to be done by
the aircraft manufacturers (probably because the novel technology applied throughout the
aircraft will introduce many new signal types which – at the present point in time – cannot
be foreseen and properly standardized)

+ AFDX payload can be used to format ARINC 429 labels as AFDX messages (thereby al-
lowing to send single label messages and multiple label messages)

+ AFDX payload formatting as Functional Data Sets possible which allows to group data in
data sets and provide status information about each data set; the grouping is carried out
according to functional and application reasons almost without considering the resulting
message size

+ connection to open world networks (i.e., passenger owned devices domain, Internet) and less
safety critical network domains (i.e., the airline information services domain and passenger
information and entertainment services domain) is easy to realize since the implementation
of AFDX is based on Ethernet and UDP/IP
1.6. CATEGORIZATION OF AIRCRAFT NETWORKING TECHNOLOGY 31

1.6.4 Controller Area Network (CAN)

Controller Area Network (CAN) is a bus system that has been developed by Bosch in the early
1980s for use in automobile networks to reduce the wiring within the automobile and thus its
weight. The specification has been internationally standardized as ISO 11898. ([CAN-P1],
[CAN-P2], [CAN-P3d], [CAN-P4]). Besides its original application area in automobiles, it is
nowadays also used in off-highway and off-road vehicles, trucks and busses, in passenger and
cargo trains, maritime electronics, automation industry and aircraft and aerospace electronics
where it has often replaced proprietary solutions. In avionics systems it is typically used by con-
trollers to communicate with smart peripherals.
The CAN data bus operates in multiple-sources-to-multiple-sinks mode and bus access is regulated
by the communication nodes itself using bit-wise arbitration of the CAN message identifier. The
message identifiers are uniquely assigned to a sender and serves as a priority measure and also
denote the message content. Message identifiers are statically assigned during system design and
can only be used by one sender to avoid priority conflicts. One sender can use different message
identifiers for different content since the CAN message identifiers are content-oriented and do not
address a specific set of receivers. Instead each receiving node can filter the CAN messages using
the identifier to decide which messages shall be handled. This means that new receivers can easily
be added to the data bus without any modifications to the previous communication nodes. Message
processing can then occur simultaneously in the nodes.
If two ore more communication nodes try to send a new CAN message simultaneously, the bus
access conflict is resolved by these nodes themselves by bit-wise arbitration of the identifiers. The
“winner” can transmit its message while the others wait until the bus is available again. This
approach helps to guarantee low latencies for high-priority or time-critical messages and builds a
hierarchy of messages. In addition, it guarantees that neither information nor time is lost since the
winner has already started transmission without time-consuming negotiation and the others know
that their message has not been sent (no information loss). The disadvantage of this approach is
that latency increases with load and – in case of faults that cause some nodes to make excessive
demands – other nodes with a lower priority may be prevented from sending their messages.
Different types of message frames are possible: data frames, remote frames, error frames, and
overload frames. Data frames contain an identifier and the data itself whereas remote frames are
requests from other nodes to someone else to send a data frame with the respective information. If
a data frame and a corresponding remote frame are transmitted simultaneously, the data message
prevails over the remote frame although both messages contain the same identifier, i.e., have the
same priority. Error frames are transmitted if a node has detected a bus error. Overload frames are
used to provide an extra delay between frames. Data frames and remote frames are separated from
the preceeding frame by an interframe space.
CAN messages can have a payload of up to 8 Bytes not including the message identifier which
defines the content of the payload. Thus, the concept of the CAN message identifier corresponds
to ARINC 429 labels. Comparing CAN with ARINC 429, CAN allows multiple senders on the
bus and provides up to 2.5 times the payload of an ARINC 429 message. On the other hand, the
protocol overhead in a CAN messages is more than 5 times the overhead of an ARINC 429 mes-
sage. Also the number of identifiers / labels is different: CAN allows up to 211 different identifiers
(standard CAN) or up to 229 different identifiers in the extended version whereas ARINC 429 only
provides up to 28 different labels.
The number of communication nodes on one CAN bus is theoretically not limited. During system
design the expected / possible delay times and the electrical loads on the bus line are calculated
to avoid too many nodes on one bus. To avoid total loss of communication with all peripheral
equipment if a CAN bus fails (either by loss of power or by interrupts of the wiring), typically,
redundant busses are used where at least one is connected to essential power.
32 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

The possible length of the bus line depends on the transfer rate: up to 40m at a transfer rate
of 1 Mbit/s (maximum transfer rate), 620m at 100 kbit/s, 10km at 5 kbit/s. Note that aboard an
aircraft, a bus length of 40 m is unrealistic for most controller-to-peripherals networks since the
controllers are typically installed in centrally located compartments whereas the location of the
sensors / actuators may be distributed over the whole aircraft (e.g., smoke detectors).
Summarizing, the advantages and disadvantages of CAN are as follows:

± definition of message identifiers at system design, but no standardized identifiers

+ multiple-sources-to-multiple-links mode means that it is well suited for controller-to / from-


peripherals communication but can also be used for inter-controller communication (e.g.,
communication between PLCs)

– arbitration method can lead to starvation of senders with low priority messages if malicious
senders want to send high priority messages; not a severe safety risk if used in static and
controlled networks

+ built-in error detection mechanisms increase reliability of transmission

– relative small payload means that CAN is not applicable for audio / video communication

1.6.5 Application-specific Busses and Protocols

In many systems, proprietary bespoke data busses and protocols are used for communication with
the peripheral equipment or for inter-controller communication. For example, the German corpo-
ration KID-Systeme has developed for the Cabin Management System CIDS for the Airbus A318
and A340-500/600 two proprietary busses: the so-called Topline and Middleline. These are used
for controlling external devices such as reading lights or Additional Attendant Panels (AAPs). A
detailed analysis of the pros and cons and a comparison with the above bus systems is outside the
scope of this thesis.
Additionally, it is possible to implement application-specific protocols on top of standard busses.

References
ARINC 429 is standardized in [ARINC429]. ARINC 629 is specified in two parts:
[ARINC629P1-5] provides the technical description and [ARINC629P2-2] an application guide.
ARINC 664 consists of seven separate documents: [ARINC664P1-1] addresses the system
concepts and provides an overview, [ARINC664P2-1] describes the Ethernet physical and
data link layer specification, [ARINC664P3-1] addresses Internet-based protocols and ser-
vices, [ARINC664P4-1] contributes Internet-based address structures and assigned numbers,
[ARINC664P5] deals with network domain characteristics and interconnection, [ARINC664P7]
specifies the Avionics Full Duplex Switched Ethernet (AFDX) network, and [ARINC664P8]
describes interoperation with non-IP protocols and services. CAN comprises four documents:
[CAN-P1] addresses the data link layer and physical signaling, [CAN-P2] the high-speed medium
access unit, [CAN-P3d] the low-speed, fault-tolerant, medium dependent interface, and [CAN-P4]
the time-triggered communication. The application of CAN in the automotive domain is described,
for example, in [Sto96]. The Topline and Middleline as examples of application-specific busses
and protocols are introduced in [Pel02b]. A comparison of different networking technologies is
provided in [MS03] and [Rus02a], among others.
1.7. DEVELOPMENT PROCESS – ARCHITECTURE AND PLATFORM DEPENDANCE 33

1.7 Development Process – Architecture and Platform Dependance

The V-Model introduced at the beginning of this chapter and depicted in Fig. 1.2 does not con-
sider in detail different architecture models, different redundancy concepts, or the use of different
platform types. Moreover, the development process as described in Sect. 1.1 presumes a federated
architecture and no development of dissimilar hardware or software. In the following paragraphs,
the differences of the development process regarding diverse development and use of IMA mod-
ules are emphasized.
Figure 1.8 depicts the development and V&V activities as typically performed for federated ar-
chitectures where each system uses unstandardized, special-to-purpose platforms. These different
platforms are developed in parallel and independent of each other. An aircraft architecture using
such a development process may use hardware or software redundancy with duplicated identical
components. The figure shows that the development of the different pieces of HW and SW equip-
ment are separate and parallel processes and that equipment duplication to achieve redundancy
does not result in additional development activities.

Aircraft

D1 D2

S11 S12 S21 S22

                    

                                    


E 111
E 112
E 121
E 122
E 211
E 212
E 221
E 222

                    

                                    

                    

                                    

                    

                                    

           

                           

           

                           

development of different   


 


 


 


 


 


 


 


 


 


 


 


  

specialized HW equipment                

               

Figure 1.8: V-Model used for federated architectures with different specialized platforms for each
system

Figure 1.9 shows the development process for an architecture using hardware redundancy with
diverse hardware equipment. In this example, system S 11 uses an architecture with redundant and
diverse hardware but with the same (duplicated) software on the different platforms. This results
at equipment level in two separate development processes – one for each diversely developed
equipment E112a and E112b .
In Figure 1.10, the development process for aircrafts using an IMA architecture is depicted. One
of the main characteristics is that different systems share the same computing resource – the IMA
platform. As a consequence, the IMA modules are developed independently from the systems’
application software. In this example, the applications E111 , E121 , E211 , and E221 are developed
according to the IMA approach (i.e., use the services provided by ARINC 653) and are then
integrated on the separately developed IMA module during system integration which is considered
in Chap. 5.
34 CHAPTER 1. DEVELOPMENT OF AVIONICS SYSTEMS

Aircraft

D1 D2

S11 S12 S21 S22

  

           
 

 

 

 

          

                                          

  

         
      


       
  
   

                      

              

E 211
E 212
E 221
E 222
   


   
  

   








   
                      
                           
              

   

  
E 111
E 112
E 112
E 121
E 122
E 211
E 212
E 221
E 222
         

      

   
   
      

                      

              

   


   
  

   








   
                                                  
              

   

  
         

      

   

       
  

                      
              

   


a
b


   
  

   








   
                           
                      
              

   

  

         

      

   

   
   
  

                      

              

   


   
  

           
                           

                      

              

   

  

         
      

   
   

   
  

                      

              

   


   
  

           
                           

                      

              

              
              

           
                           

              
              

              
              

               

              
              

              
              

diverse development of 





























































specialized HW equipment

Figure 1.9: V-Model depicting the parallel development of diverse platforms for system S 11

Aircraft

D1 D2

S11 S12 S21 S22


E 111

E 121

E 211

E 221

no development of
specialized HW equipment

development of
IMA platform

Figure 1.10: V-Model showing the development process as used for IMA architectures where
standardized IMA platforms are developed once and then used by different systems
Chapter 2

Testing of Avionics Systems

The life cycle model introduced in the previous chapter assigns the tasks needed for building
an aircraft to two main processes: the development process and the verification and validation
process. The development activities were the subject of the previous chapter – particularly in
Sect. 1.1 and Sect. 1.7. The verification and validation (V&V) process shall be examined in this
chapter. Verification and validation are defined as follows:

• Verification is the process of determining that a system or one of its parts meets its specified
requirements. Thereby, the focus is on showing the conformance with the requirements
and design specification rather than demonstrating the actual correctness. This means that
correct and complete specification documents are required which is examined by validation
activities. Two sub-processes are distinguished:

– Requirement verification shows the compliance of a requirement with its respective


higher-level requirement.
– Implementation verification demonstrates that a hardware or software component, a
subsystem or a system complies with its respective requirement and design documents
(e.g., system with SRD and SDD).

• Validation is the process of determining that a system and its requirements are appropriate,
consistent and complete and reflect the customer requirements and expectations. There are
the following validation sub-processes:

– Requirement validation is performed on requirements and design decisions and deter-


mines if the requirements are adequate, clear, correct, consistent and complete. The
results of this sub-process are validated requirements to be used for verification. Ex-
perience has shown that early validation of the requirements (ideally before further
detailing them) can identify subtle errors or omissions and thus may reduce costs and
time for late redesign of inadequate requirements or even systems.
– Implementation validation is performed on the implemented product and determines
that it is appropriate for its purpose and meets the customer requirements.

The primary aim of the V&V activities is to increase confidence in the development process and
the implementation. Further, it shall provide the necessary documents required for certification
of the aircraft. Certification means to convince some external regulating body that the aircraft
is safe and complies with the applicable requirements and standards. It is practically impossible
to guarantee the correctness and safety of a complex system for all situations and the absence of
any faults, but the verification and validation shall demonstrate an acceptable level of correctness,
completeness, reliability and safety. The selection of useful methods and the extent to which each

35
36 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

needs to be applied is the result of agreement with the certification authorities with regard to the
standards and regulation documents referred to by the certification authorities. A verification and
validation plan subsumes the agreement and determines the organizational responsibilities, the se-
lected methods, the environment, and guidelines for re-verification. The selection process depends
essentially on the associated development assurance level. However, to simplify development and
certification, a Functional Hazard Analysis (FHA) is performed at the beginning of the develop-
ment process to identify potential functional failures and to assign a failure condition category to
each function, system and subsystem. If multiple categories of failure conditions can be associ-
ated with the aircraft’s different functions and the respective systems and subsystems and if the
interaction between the systems or subsystems is limited by appropriate means (e.g., by architec-
tural separation of the systems), different development assurance levels (DAL) can be assigned to
each part. For the certification of the aircraft, each platform type and application software part is
certified independently according to its respective DAL and then combined. Thereby, the V&V
effort for systems and components considered less critical can be reduced which as a consequence
reduces the overall costs and time spent for verification and validation.
Note that verification and validation activities are also performed on V&V documents. In partic-
ular, the test design documents and the test results are analyzed and reviewed. The test design
documents describe which features have to be tested and how and relate these descriptions to the
requirements of the respective development level (i.e., tests on system level are related to system-
level requirements). The objective of analyzing the test design in relation to the requirements is
to confirm that the tests satisfy the specified criteria, define the expected results, and are described
clearly and accurately. Test result analysis shall ensure that the test results are correct and that
discrepancies between actual and expected results are explained.
In this chapter, we will focus on testing as one of the most promising implementation verification
methods that allow extensive automation and thus can help to reduce time and costs for certifi-
cation and re-certification. To provide an overview of the different parts to be considered during
verification and validation, the following section (Sect. 2.1) briefly subsumes methods for veri-
fication and validation. Section 2.2 then discusses the approach for aircraft integration and the
respective testing activities. An essential part of testing are the test design documents which are
addressed in Sect. 2.3. These documents define the tests to be carried out. Of particular interest is
the question which formalisms are used for defining the tests (i.e., the test cases and the test pro-
cedures). The different specification techniques (which are also reviewed in Sec. Sect. 2.3) lead
to different restrictions regarding test data generation and test execution which are both discussed
in Sect. 2.4. In addition, the formalisms may impose restrictions on the means for test evaluation
and error diagnosis. These are also considered in Sect. 2.4.

2.1 Overview of Verification and Validation Methods

Verification and validation methods in general are applied to

• the requirement and design documents,

• the results of the development process (i.e., the hardware equipment, their system software,
and the application software),

• the verification and validation documents (e.g., the test design documents and the verifica-
tion and validation plans), and

• the results of the integration and V&V activities.


2.1. OVERVIEW OF VERIFICATION AND VALIDATION METHODS 37

The applicable and useful methods are recommended in the respective standard documents (e.g.,
[DO-178B], [DO-160E]), recommended practices (e.g., [ARP4754]), and airframer directives
(e.g., [ABD200]). Among others, requirement and implementation verification activities for soft-
ware are considered in RTCA / DO178B ([DO-178B]). RTCA / DO-160E ([DO-160E]) considers
standard procedures and environmental test criteria for airborne equipment. Implementation ver-
ification is also regarded in [ARP4754]. Review and analysis methods for test case and test pro-
cedure verification are considered in RTCA / DO178B ([DO-178B]) for software systems and can
be applied similarly for aircraft systems. Means for requirement validation are discussed among
others in [ARP4754]. Since all verification and validation activities are performed to achieve
equipment or aircraft certification, the importance of these standards and recommended practices
is demonstrated by the numerous references in the certification guidelines of the regulation author-
ities (i.e., of the European Aviation Safety Agency (EASA) and the Federal Aviation Administra-
tion (FAA)). This includes, for example, the IMA-related guidance documents [AC20-145] and
[TSO-C153] which are both issued by the FAA.
The verification and validation plans are compiled for each level (from aircraft level to equipment
level) and agreed with the certification authorities. They define in detail the combination and se-
quence of V&V activities, the documents to be produced, the verification environment (e.g., the
test rig setup), the roles and responsibilities, and means for maintaining the status of verification
or validation after changes to the requirements or to the produced component. The plans are each
accompanied by a schedule. Note that the effort (with respect to cost and time) for generating
verification-specific hardware and software should not be underestimated because this includes
planning, developing and assembling a test rig, selection of a test tool and development of the
required interfaces to the system under test, development of simulations, among others. Addi-
tionally, the schedule should plan in advance that validation or verification activities may detect
deficiencies and that some development and V&V activities have to be repeated.

Verification Methods. Verification consists of the following complementary methods:

• Inspections and reviews typically use a checklist or similar aid and provide a qualitative
assessment of correctness. Questions addressed by inspections and reviews are the clar-
ity and completeness of the description (requirements, test cases, test procedures, and test
results, irrespectively), the compliance of the document with documentation standards, con-
sistency of the terminology and with related documents, correctness with respect to the aim
of the document, data usage regarding types and specific values, and evaluation of inter-
faces, maintainability, performance, reliability, testability and traceability.
Inspections and reviews can be applied to all documents of the development and verification
process (i.e., specification documents, source code and equipment, V&V documents, and
V&V results).
• Analyses examine in detail a functionality, a system’s or component’s performance, require-
ments traceability or coverage of the requirements by the implementation. Analyses can
be applied to the results of the development process (e.g., code analysis) as well as to the
results of the verification process (e.g., test case traceability analysis). In comparison with
review methods, analyses provide repeatable evidence of correctness. Unlike testing, analy-
sis methods look at the characteristics of a component that indicate or suggest the presence
of some kind of faults. Analysis methods can evaluate the entire operating range of a compo-
nent and are thus an important complement to testing if exhaustive testing is impossible due
to an infinite number of test cases. A further difference to testing is that analysis methods ex-
amine the component without executing it, i.e., they can be applied on non-executable code
fragments or modules. Typical analysis techniques are formal proofs, semantic analyses,
control flow analyses, data flow analyses, symbolic execution (also called model checking),
and metrics.
38 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

• Testing provides repeatable evidence of compliance with the requirements by exercising


the respective component in an appropriate environment. Testing is applied on the results
of the development process. It executes the respective component and is thus the only
method to investigate the timing performance of a system or component (in particular by
performance and stress testing). Testing is categorized by the chosen test case selection
strategy resulting in three types of testing: functional testing, structural testing, and random
testing. Functional or requirement-based testing is a black-box approach, i.e., no detailed
knowledge about the implementation is required. Structural or coverage-based testing uses
detailed knowledge of the internal structure to investigate the characteristics and thus is a
typical white-box approach.
If the operational environment of a component or system is not available or cannot be used
during testing, environment simulations or test stubs can partially or fully replace the real
environment.
• Service Experience Analysis is applied to increase the confidence in the requirements and
design and is based on documented experience reports of another similar system that is
already in use in a similar environment. The reliability of this verification method obviously
depends mainly on engineering judgment that the system or component is similar enough
and installed and used in an adequately similar environment.
Note that most avionics systems are developed further from one to another application area
to add more functionality or to remove undesirable behavior. It is then difficult to guarantee
adequate similarity for the respective system.
It is outside the scope of this thesis to discuss in more detail which combination of verification
methods is most commonly used in which life cycle phases. Storey ([Sto96], p. 325) provides a
possible list of verification methods and their assignment to particular life cycle phases. ARP 4754
([ARP4754], p. 55) proposes for each development assurance level a list of verification activities
that are recommended, to be negotiated or not required for certification. The appropriate selection
for a given safety-critical system is guided by the respective standards and directives and then
negotiated with the certification authorities. Typically, several methods are used in each phase to
cover statical and dynamical aspects.

Validation Methods. Validation methods are particularly using structured reviews, analyses and
execution of the component under validation to check the completeness and correctness at each
hierarchical level of requirements and design decisions and to determine that the regulatory stan-
dards and guidelines have been applied. Safety-related analyses are usually based on the results of
a Functional Hazard Analysis (FHA), Failure Modes and Effects Analysis (FMEA) and Prelimi-
nary System Safety Assessment (PSSA). In addition, similarity with an in-service certified system
or component can increase the confidence in the quality of the requirements and the design.
Before the final product is developed or available, the specification can be validated using a sim-
ulation which is developed either in an automated way animating a formal specification or by
manually implementing a simulation or prototype from a possibly non-formal specification.
The selection of appropriate and necessary validation methods depends on the failure condition
category of a system or component and the techniques used for specifying the system. The vali-
dation plan comprising this selection has to be agreed with the certification authorities. Detailed
instructions are outside the scope of this thesis, but, for example, ARP 4754 ([ARP4754], p. 49)
provides for each development assurance level a list of recommended validation methods.

Focus on Testing. In the following, we will focus on testing including test case specification,
test data generation, test execution and test evaluation although its main disadvantage is that it
may only detect existing faults but cannot guarantee that a system is free of faults. Nevertheless,
focusing on testing is motivated by the following reasons:
2.2. SYSTEM TEST APPROACH FOR AVIONICS SYSTEMS 39

• Current standards and directives in avionics put much emphasis on testing as the essen-
tial verification method and suggest to apply other verification methods to complement the
verification activities (and thus to overcome the disadvantages of testing).

• Tests are the only way to check the performance of a component or system in normal and
stress situations.

• Testing can become more cost effective if adequate (i.e., usually automated) test data gener-
ation, test execution and test evaluation techniques are applied.

• Performing reviews, inspections and analyses are manual methods and require an extensive
amount of engineering judgment, consequently they are less subject to automation and thus
to cost reduction.

• In particular, formal analysis (i.e., model checking) requires much expertise from the user
since it is often necessary to formulate the problem in a form which is able to circumvent
the shortcomings of the available tools (e.g., to avoid the so-called state explosion problem).

• Complete formal proofs (e.g., by model checking) are usually impractical for systems with
the degree of size and complexity that we are facing here.

• In general, it is not feasible to provide a complete formal specification for realistic industrial
systems if the hardware specifications and the integration of real-time aspects are consid-
ered. Thus, a formal analysis of the complete system is often impossible.

• Approaches to support validation methods and to simplify test case generation and simula-
tion are addressed by current and future research topics, e.g., in the research project KATO
(see [OH05]) and in the research project HYBRIS (see [BBHP04] and [BZL04], among
others).

References
The standard document [DO-178B] includes considerations for the development and verification
of software in avionics systems. [DO-160E] focuses on the hardware part and considers stan-
dard procedures and environmental test criteria for airborne equipment. Recommended prac-
tices for development, verification, validation and certification of aircraft systems are compiled
in [ARP4754], [AC20-145] and [TSO-C153], among others. Respective airframer directives can
be found, for example, in the Airbus directive [ABD200]. A detailed discussion of verification,
validation and testing of safety-critical systems is provided in [Sto96] (particularly in chapter 12).

2.2 System Test Approach for Avionics Systems

Generally, different strategies are possible for system integration and the associated testing. These
are:

• a non-incremental or “big bang” integration strategy integrates all components and systems
in one step

• incremental integration strategies integrate in each step one or few system components fol-
lowing a

– bottom-up approach: one integration process starting with the “smallest” components
(e.g., at equipment level),
– top-down approach: one integration process starting at top level (e.g., at aircraft level),
40 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

– available-components-first approach: one integration process starting with the first


available component and step-wise integration of further available components,
– function-oriented approach: one integration process per (aircraft) function which step-
wise integrates the respective systems and components,
– business-process-oriented approach: one integration process per business process or
use case integrating step-by-step all systems and components contributing to this use
case (e.g., from boarding to de-boarding of the passengers),
– outside-in approach: two integration processes starting simultaneously at bottom and
top and moving towards each other,
– inside-out approach: two integration processes starting at medium level and moving
simultaneously towards bottom and top level,
– hardest-first approach: one integration process starting with the most critical compo-
nents.

All incremental integration strategies need test stubs, dummies or simulations of components
which have not yet been integrated but are necessary for the already integrated components. De-
veloping adequate test stubs or simulations is a costly process that can be avoided using a big-bang
strategy. However, this non-incremental approach has many disadvantages: all components have
to be available beforehand, error diagnosis and localization is difficult due to the collaboration
of too many new and possibly erroneous components, and it often leads to an unstructured and
unsystematic approach if problems occur and cannot be easily isolated and localized.
Integration strategies applied in avionics are typically combinations of different approaches pre-
pared and applied concurrently: The main strategy is to follow a bottom-up approach starting at
equipment level by assembling the platforms (i.e., by integrating the operating system software
into the equipment’s hardware) followed by the integration of the application software into the
platform. The next step on system level integrates the components of each system, which are
then assembled on domain level and finally on aircraft level. At each level, the current integration
activities can focus on the respective details, e.g., on equipment level on hardware or software
requirements, on system level on system requirements. These integration activities can be per-
formed at different sites, e.g., the platform integration at the platform supplier’s site, the system
integration at system supplier’s site, the domain integration at domain integrator’s site, and the
final aircraft level integration at airframer’s site.
The main integration process is accompanied by further integration processes at each level which
can apply different integration approaches. For example, at system level, an available-components-
first approach, a hardest-first approach or a bottom-up approach are most meaningful strategies
while on domain and aircraft level additionally function-oriented or business-process-oriented ap-
proaches constitute promising strategies. In future, the airframers envisage on all levels to ap-
ply more test-objective-oriented integration strategies (i.e., function-oriented or business-process-
oriented approaches) rather than adhering to the currently applied procedure-oriented integration
strategies (i.e., bottom-up, top-down, inside-out, outside-in, or hardest-first approach). Possibly,
this may lead to a set of integration processes that are mainly business-process-oriented and each
consider aircraft to equipment level requirements. Each such integration process may follow a
function-oriented approach focusing on aircraft or domain functions. By this new approach, air-
framers hope for improvement of the travel quality by ensuring that the business processes are
convenient, effective and coherent for passengers and crew members.
Also today the previously described main integration process is not exclusively a bottom-up ap-
proach. In fact, it is an outside-in approach, i.e., the above described bottom-up approach is
accompanied by a top-down approach starting at aircraft level. For example, the assembling of the
so-called iron bird is started while functional tests on equipment and system level are still carried
2.2. SYSTEM TEST APPROACH FOR AVIONICS SYSTEMS 41

out. An iron bird is a full size system integration test rig that integrates most avionics systems and
their original equipment and wiring in a laboratory environment without scaling the size and num-
ber of hardware components.1 This allows, for example, to examine the effects of original cable
lengths and the actual power consumption. Obviously, this second integration process focusing on
assembling an iron bird or an aircraft mock-up is at first more hardware-oriented while the main
bottom-up approach initially focuses on software integration and HW/SW integration.
The integration process is accompanied by verification and validation activities, in particular by
integration testing as depicted in Fig. 2.1. At equipment level, platform tests and application
software tests are performed. At system level, system tests and multi-system tests are executed.
After integrating the systems of all domains into the aircraft, ground tests and flight tests can
be carried out. Figure 2.1 also emphasizes that at bottom level there is one test process for each
platform and each application software, while after hardware / software integration there is one per
integrated platform and so forth. Note that flight tests, ground tests and partially system integration
tests are on-aircraft tests while the others are laboratory tests that each use their specific integration
testing environment and appropriate simulations for components and systems not yet integrated.

Aircraft

D1 D2 Flight Tests
Ground Tests
    

System Integration Tests


    

         

S11 S12 S21 S22 















   















   
Multi-System Tests
    

             






      

             







      

System Tests

             






      

Qualification Tests
            

                           

    

    
E 111
E 112
E 121
E 122
E 211
E 212
E 221
E 222

    

            


    
                          

    

  












  













  













  







  





  


 







Platform Tests
    

Application Tests
    

            

                          
    

    

    

    

            

                          

    

    

    

    

       

                

    

    

    

    

       

               

       

               

       

        


        

Figure 2.1: Integration testing activities: (a) platform tests including hardware and operating sys-
tem tests (green pattern), (b) application software tests (red pattern), (c) system tests (blue pattern),
(d) multi-system test within one domain (dark blue pattern)

2.2.1 Platform Testing


The process of platform testing considers testing of the physical hardware, testing of the specific
operating system (OS) implementation, and testing the integration of the OS onto the hardware.

Hardware Testing. Hardware equipment testing includes functional tests and environmental
tests whereby the latter include mechanical, electrical, electronic and other tests. Thereby, the
compliance with functional and safety requirements is examined under normal and exceptional
operational conditions with respect to temperature variation and in-flight loss of cooling, pressure
drop, decompression, overpressure, humidity, shock and crash safety, vibrations, acoustic vibra-
tions, explosion, waterproofness, sand and dust, magnetic effects, icing, fire, and power consump-
tion. The respective environmental testing methods and approaches are defined in the standards
1
A smaller version of the iron bird is a so-called mini bird that uses only one or very few originals per component
type and replaces the others with software simulations. The testing possibilities are limited with respect to an iron bird,
but less laboratory space is required.
42 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

and directives (e.g., [DO-160E], [ABD200]) but are not further detailed in this thesis. Note that
the hardware characteristics of sensors, actuators and other equipment are verified similarly.

Operating System Testing. Operating system testing is focusing on functional tests under dif-
ferent operational conditions to also verify the robustness of the system under test. Thereby, the
environment of a platform may need to be simulated, e.g., to test the interface driver part of an
operating system, external communication partners have to be simulated to check the sending and
receiving of data and the compliance with the respective standards.

Integration Testing. Testing of the platform’s operating system can be performed on two levels:
at software integration test level and at hardware/software integration test level. Software integra-
tion test level means that a software simulation of the target hardware is used to test the OS. At
hardware/software integration test level, the OS is tested on the target hardware which itself has
been tested separately as described above. The result of the hardware / software integration is a
tested and integrated platform that may be subject to certification. Note that for certain platform
types and if platform and application software is developed by the same supplier, certification can
be postponed until the application software has been integrated.

The responsibility for platform testing varies depending on the type of platform or the combination
of hardware and operating system as described for each platform type in Sect. 1.5.
For shared platforms (e.g., if IMA modules are used), the test process is described in detail in
Chap. 5.

2.2.2 Application Testing

Application testing focuses on testing the application software which shall later be executed on
the respective platform. It can be performed at module test level, at software integration test level,
or at hardware/software integration test level.

Module Testing. At module test level, units of the software, e.g., specific functions or algo-
rithms, are tested. The respective module is executed in a simulated environment, i.e., simulations
and test stubs are required. Therefore, it is often only performed for highly critical parts to avoid
the preparation effort. Testing at module test level may stepwise progress to testing the complete
application software if an incremental integration strategy is applied on this level that replaces in
each step a module’s test stub with the respective module.

Software Integration Testing. At software integration test level, a simulation of the target plat-
form is used to execute the application software which may allow to access parts of the platform
which are normally protected. For example, a platform simulation may allow access to the ap-
plication’s memory areas. Testing at this level can only be performed if a platform simulation is
available.

HW/SW Integration Testing. At hardware / software integration level, the application software
is executed on the (tested) platform. If a platform is not shared, the testing activities at this level
result in a tested controller (i.e., a tested platform with tested and integrated application software)
and are the basis for certification of the controller.

For applications to be integrated onto a shared platform (e.g., IMA module), the V&V activities
are considered in more detail in Chap. 5.
2.2. SYSTEM TEST APPROACH FOR AVIONICS SYSTEMS 43

2.2.3 System Integration

System integration assembles the controllers and peripheral equipment of a system that each have
been tested at equipment level. For federated and IMA architectures, the interacting systems are
simulated. At this level, testing of the system architecture’s redundancy concept can be completed.

2.2.4 Multi-System Integration

At this level, the systems belonging to the same domain are integrated and their interaction is tested
for normal and exceptional operational environments. Systems belonging to other domains are
still simulated. For an IMA architecture, this test level may be more important because different
systems of the same domain may share an IMA module. Multi-system integration is typically
performed at one site per domain (e.g., Toulouse for the cockpit domain and Hamburg for the
cabin domain).

2.2.5 System Integration Testing

System integration physically assembles all domains (i.e., all systems) at one site. The aim of
system integration testing is to ensure that they all operate correctly – individually and together –
when installed in the aircraft. For first integration steps, laboratory environments like an iron bird,
a mini bird or an aircraft mock up are often considered more meaningful and cost-effective than
on-the-aircraft integration. Nevertheless, difficulties with fully modeling the aircraft environment
may dictate that some integration activities are performed on aircraft.
The system integration process may encounter various problems, for example, it may be phys-
ically impossible to fit the hardware into the laboratory where the integration is to take place.
Further, physical integration means that at first the focus is on hardware integration and related
problems (e.g., connectors or plugs do not fit) rather than on the interaction of the systems and
the related problems (e.g., incomplete/incompatible interfaces, interface misinterpretation, con-
figuration problems). To overcome some of these drawbacks, the system integration testing can
be performed in two separate phases: During the first phase, the domains are virtually integrated
by connecting the multi-system integration test rigs which are typically located at different sites,
and in the second phase, the systems are physically integrated at one site. For the first phase, it
has to be considered that different test systems might have been used for each multi-system in-
tegration test rig which typically do not provide means for cooperation with other test systems.
Therefore, it is necessary to have a coordinating component (e.g., a test management tool) that
supports interoperation between different test systems by managing distributed test preparation,
test execution and test archiving. Adequate communication links have to connect the test systems
and the domains (i.e., the systems under test) to allow management-related communication as well
as data exchange between the systems under test. This concept has been developed in the research
project VICTORIA by the author and Terma A/S and has been implemented by Terma A/S and
Airbus. It has successfully been applied to connect systems located in Hamburg, Toulouse and
Filton (for the concept see [TPLB03]). Note that virtual integration may also be applied at earlier
test levels to avoid the development of simulations for components which are available at other
sites as simulations or original items but cannot be integrated in the local test rig.

2.2.6 Ground Tests and Flight Tests

These tests are in-aircraft tests and the focus is on correct cooperation between the systems in their
original and final environment under normal and exceptional conditions. Principally, these tests
repeat some of the tests executed at previous levels in laboratory environments or with simulated
components but with special emphasis on the aircraft level requirements and functions. They are
44 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

completed by additional tests. For example, special vibration tests on ground are performed to
ensure that plugs and connectors remain connected. For the development of a new aircraft, the
first flight – the maiden flight – is of special importance and is not carried out until extensive
ground testing and on-ground flight testing (e.g., taxiing, performance tests on ground, roll tests
up to a speed closed to take-off speed) has been executed successfully. Further details on these test
phases are outside the scope of this thesis.

References
Integration strategies and their pros and cons are discussed in [Bal98]. The system test approach
for avionics systems is addressed in [ABD100], [ABD200], [ARP4754], among others. More
information about ground testing and first flight can be found, for example, in the A380-related
articles [Sch04] and [Lab04].

2.3 Test Design Documents

2.3.1 Test Case and Test Procedure Selection

The test design documents are compiled during the development phase to prepare the verification
and validation phase. They elaborate on the features to be tested by specifying test cases and test
procedures.
A test case description consists of a purpose for the test case, a set of inputs, conditions and ex-
pected results to achieve the required coverage, and a pass / fail criteria. Each test case is related
to one or more requirements of the respective level (e.g., for system level tests to system require-
ments).
A test procedures describes in detailed how each test case is to be set up and executed, how the test
results are evaluated, and how the test environment has to be configured. Often, a test procedure
can combine several test cases.
A test specification is that part of a test procedure that considers the inputs to and outputs from the
SUT and the timing requirements. Test specifications do not consider configuration and organiza-
tion aspects like how to configure the test system or where to store the test execution log.
For automated test data generation or automated test execution (addressed in the next section), it
is often necessary to get additionally an implemented test procedure that uses the specification for-
malism of the test tool for describing the test specifications and contains appropriate configuration
data (complying to the needs of the test tool and the test bench).
Different strategies can be applied for test case selection which ensure that all important situations
are tested:

• functional or requirement-based test case selection


This strategy is a black-box approach that has the point of control and the point of obser-
vations outside the system under test and cannot use any internal information. It is often
applied for higher test levels since it focuses on functional aspects.
Black-box approaches may analyze equivalence classes and their boundaries, may select
special values (e.g., zero values) in order to cover the state space and the possible transitions
of the SUT.

• structural or coverage-based test case selection


This strategy needs detailed knowledge about the internal structure to control and to observe
the behavior of the system under test and thus is a white-box test approach. It is typically
used for lower level test cases, e.g., on equipment level.
2.3. TEST DESIGN DOCUMENTS 45

White-box approaches usually analyze the code statements of the SUT and the respective
branch conditions in order to cover all statements at least once. More elaborated structural
coverage criteria are also possible (e.g., branch condition combination coverage or patch
coverage).

• random test case selection


The aim of this selection strategy is to choose randomly test cases without generating them
systematically or deterministically. The selection can be based on both requirements and
structural information and thus cannot be categorized as black-box or white-box approach.
Random test case selection can complement a systematic approach by adding test cases
which have not yet been considered by the test case designer. It should not be used as the
primary strategy since it may take to long to achieve the required test coverage.

• intuitive test case selection


For this strategy, the test case designer use their intuition and experience to generate test
cases which typically lead to erroneous situations. It can be used to complement systematic
requirement- or coverage-based strategies, but should not be the only selection strategy.

Test coverage criteria determine if enough and adequate test cases have been defined, e.g., to cover
all requirements, to structurally cover the requirement specifications, or to structurally cover the
code structures. The same criterion is used after test execution to analyze the test coverage in order
to find out if enough test cases have been executed.
Test procedure selection approaches select test cases with matching pre- and post-conditions,
i.e., test cases where the execution of one test case establishes conditions (defined by the post-
condition) complying with the pre-condition of the next test case. Additionally, a test procedure
often combines test cases with similar test objectives testing a specific feature of the SUT. Fi-
nally, appropriate test sequence selection approaches determine the sequence of test procedures,
e.g., according to the configuration of the SUT or the test system, or according to the pre- and
post-conditions of the test procedures.
For testing of avionics systems and software, RTCA / DO178B emphasizes requirement-based test
case selection “because this strategy has been found to be the most effective at revealing errors”
([DO-178B], p. 30) in combination with a two-part coverage analysis: a requirement-base one and
a structural coverage analysis (see [DO-178B], p. 33). As a consequence, the specification docu-
ments defined during the development phase (see Chap. 1) are of special importance since they are
the basis for the test design documents, i.e., the test cases and test procedures. In particular, the
formalism used for specifying the structural and behavioral aspects of the component has a major
impact on the possibilities for automated test case selection, or the expressiveness and clearness of
the specification necessary for manual test case selection. Many different formalisms can be used
for requirement specification. Most of them can generally also be used for defining the test cases
and the test procedures. Note that it is even possible to use the same specification model for the
requirements and for the tests.
As a matter of fact, each formalism may impose specific restrictions on how test case can be
selected from requirement specifications, how test data can be generated from the test specifica-
tions, and how the test can be executed using the (implemented) test procedure. In particular, the
specification technique determines if a clear and unambiguous semantics is defined and if tool
support and automation are possible and available (and to which extent). As stated above it is
possible – and tempting – to use the same specification model for requirement and test specifica-
tion (especially with tools at hand executing the specification model to generate test inputs and
to evaluate the SUT outputs), since this eliminates one source of errors occurring when manually
defining the test cases and test procedures. Nevertheless, usually separate specifications are used
for development and verification documents of safety-critical systems. Furthermore, development
specifications are rarely compiled using a formalisms that can be used for automated test case
46 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

generation or even automated test data generation. One reason for this is the lack of adequate
specification techniques which allow clear and unambiguous specifications, but are well suited to
discuss the requirements on management level. It is the aim of current research projects to provide
appropriate specification techniques and adequate means for simulation and model-based testing
in order to eliminate or reduce the manual steps from requirement specification to test cases (see
also [OH05], among others).
In the following, we will discuss briefly different state-of-the-art specification techniques used for
development as well as for V&V documents. Each subsection shall analyze the pros and cons
of the specific set of techniques with respect to expressiveness and ambiguity, and give a brief
explanation of the restrictions for test case selection, test data generation and test execution. Note
that test data generation and test execution are addressed in more detail in Sect. 2.4.

2.3.2 Specification Techniques

The different state-of-the-art specification techniques can be categorized as informal, semi-formal


and formal. Formal specification techniques have a well-defined syntax and a mathematically
defined semantics typically given as an operational semantics or a denotational semantics. Semi-
formal specification techniques lack the mathematical rigor associated with formal methods, but
use structured techniques to restrict the variability and ambiguity of statements given by informal
specification techniques. The distinction between the categories – especially between informal and
semi-formal specification techniques – is not strict, in particular since any combination of tech-
niques can be used when describing the requirements and the design. The following sections deal
with these three groups of specification techniques and provide sub-categories: Section 2.3.2.1
addresses informal specification techniques, Sect. 2.3.2.2 regards semi-formal specification tech-
niques, and Sect. 2.3.2.3 considers formal specification techniques. Section 2.3.2.4 then elaborates
on an example that compares three specifications for the same part of an ARINC 653 operating
system – the operating modes of a process (see also Sect. 3.1.2.2).

2.3.2.1 Informal Specification Techniques

Informally specified documents comprise definitions in natural language text, as figures and graph-
ical depictions, or as informal tabular notations using natural language.
Using natural language in a precise and unambiguous way without producing unreadable text is
a difficult task. The understanding relies on the readers and writers using the same words for the
same concept (lack of clarity). Furthermore, natural language is over-flexible since the same thing
can be expressed in different ways and it is up to the readers and writers to identify the equality or
difference (lack of consistency). Also, it is difficult or rather impossible to check the completeness
of the specification.
Figures and graphical depictions include all forms of block diagrams and informal diagrams. They
pretend to be an easy intuitive formalism but detailed understanding is often restricted by different
understanding of the relations between the figure elements or by mixing different specification
levels without noticing. They are typically combined with natural language labels or descriptions
and the problems with respect to clarity, consistency and completeness remain.
Informal tabular notations try to structure the pure natural language text but contain the same
(above described) problems like the natural text descriptions.
Requirements and design documents using informal specification techniques cannot be converted
into source code, code fragments or test cases in an automated way. Moreover, it is a pure manual
process to identify and combine the relevant information adequately. Nevertheless, these draw-
backs are often accepted or irrelevant for specifications on aircraft, domain or even on system
2.3. TEST DESIGN DOCUMENTS 47

level. As a consequence, test cases and test procedures for the respective level have to be gener-
ated manually by test case designers in cooperation with domain experts.
Note that the above stated problems occur in all specifications using combinations of formal or
semi-formal specification techniques with natural language supplements.

2.3.2.2 Semi-Formal Specification Techniques

To this group of specification techniques belong structured text with tables, graphical languages
with text annotations, virtual reality environments, scripting and programming languages, and
various special-to-purpose formalisms.

Structured text with tables structure natural language specifications using tables and “writing”
rules for structured text and thus provide a more clear and complete specification. The writing
rules can provide syntactical and semantical restrictions, but still fail to provide a complete (or
even formal) semantics.

To the class of graphical languages with text annotations belong formalisms like UML which are
often considered to belong to the group of formal specification techniques but miss a formal (i.e.,
mathematical) semantics (exceptions are described below). In fact, the respective diagrams pro-
vide more clearness and precision than natural language descriptions but may still be ambiguous.

Other possibilities of creating test specifications are specialized virtual reality environments that
can provide means for developing test specifications by interaction with a virtual reality (VR)
representation of the system under test. From these interactions, a formal test specification is gen-
erated by domain experts with detailed knowledge of the system under test and its environment but
who are not familiar with formal methods. Nevertheless, the semantics of interactions within the
VR environment, the formalism of the generated test specifications as well as the transformation
function might not be fully formally described.

Scripting and programming languages have a well-defined syntax and an (implemented) semantics
but usually miss a formal semantics. A well-known example is the Testing and Test Control
Notation (TTCN-3) that is a standardized “test specification and test implementation language that
supports all kinds of black-box testing of distributed systems” ([GHR+ 03], p. 1). Other formalisms
are less focused on testing (e.g., shell scripts, Windows batch files, Python, Perl, C, C++). Pseudo
code used for specifying the requirements or tests can also be used, but the syntax is usually only
informally described and an implemented semantics is not available.

Furthermore, various special-to-purpose specification techniques are used that may have a seman-
tics known to the domain experts (i.e., the writers of the requirements and probably the test case
designers) but which may not be formally defined. The drawback is that the specifications are not
commonly understandable to other experts without more or less detailed domain knowledge (e.g.,
test tool developers). Examples are forms of event-state matrices, among others.

Summarizing, requirements and design documents defined in semi-formal specification techniques


provide more clearness and precision – especially to the domain experts –, but may lack a precise
and unambiguous formal semantics. Nevertheless, there are some techniques designed for defin-
ing test cases and test procedures (e.g., TTCN-3) that have a standardized syntax and semantics
and allow the automated test data generation, test execution and test evaluation by appropriate
tools. Other tools may support the use of special-to-purpose specification techniques by having an
implemented but not necessarily clearly defined semantics how to interpret the test specifications.
If expected and implemented semantics are different, this may lead to unexpected and surprising
tests.
48 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

2.3.2.3 Formal Specification Techniques

Formal specifications techniques include mathematical formulas, sets, statecharts, and many oth-
ers. Also, there are several approaches to define a precise and formal semantics for semi-formal
graphical notations like UML – in particular, precise UML, and HybridUML, among others. Hy-
bridUML is reviewed briefly in one of the next paragraphs.
Mathematical formulas and sets are inherent formal but usually have no graphical representation
to simplify communication about the specification and lack a formal notation of time to deal with
real-time features of the system. Further features that are missing but should be provided to spec-
ify real-time and reactive avionics systems are a concept of hierarchy (to simplify abstraction of
views and to concentrate focus on relevant properties), notion of parallel composition (to sup-
port a modular development), and separation of concerns (to distinguish between architectural and
behavioral issues).
There are several semantics of statecharts described in the literature (see references below) that are
well-applicable for defining the behavior of a system, but not for specifying specific architectural
aspects. Furthermore, statecharts cannot be used to define time-continuous aspects.
The list of other formal specification techniques is extensive, for example, Communicating Se-
quential Processes (CSP), Timed CSP, the Z notation, timed automata, duration calculus, hybrid
automata, CHARON, among others. It is outside the scope of this thesis to provide further details
to all these specification techniques and the respective tools, or to compare their expressiveness for
specifying reactive real-time systems and their usability for automated test data generation and test
execution. In the following paragraph, we will very briefly introduce CSP since this formalism is
used in Chap. 6 to define test specifications. Afterwards, the basic information about HybridUML
are presented since the example in Sect. 2.3.2.4 contains a HybridUML diagram. For all other
formalisms, the references paragraph at the end of this section provides a list of publications de-
scribing their respective fundamentals and providing further links.
The use of formal – mathematically based – methods for design and specification of the require-
ments and for design and implementation of tests increases. The resulting advantage is that the
specifications have a well-defined and precise semantics and most formalisms can be used for
automated test case generation or test execution. Nevertheless, it is common praxis to define the
requirements in natural language and transform them in formal specifications to make use of au-
tomated test case selection algorithms and analysis methods (e.g., deadlock and lifelock analysis).
Thus, the main bottle-neck of current testing methodologies which rely on many manual steps
shall be avoided.
However, using formal specification techniques does not necessarily provide better and more read-
able specifications since not all formalisms suite every problem and non-functional properties can
usually not be addressed by most formalisms. Although being unambiguous and precise (and thus
assumed to be “better”), understandability for all human actors in the development and verification
process (i.e., managers, systems and software engineers, etc.) is an important factor for acceptance
– especially in the earlier phases. Typically, graphical notations simplify the communication about
the specification, especially, if hierarchy and abstraction are supported, too. Also appropriate tool
support is important.

CSP. The formal specification language CSP has been developed by C. A. R. Hoare and provides
means for specifying communicating, concurrent systems based on synchronous communication.
The basic elements of a CSP specification are the processes and the events used by the processes to
interact with each other and the environment. This paragraph shall provide an informal description
of CSP and its extensions for real-time aspects called Timed CSP. The syntax and further exam-
ples are additionally described in Appendix A. For gaining further (more formal) details regarding
the formal semantics of CSP and Timed CSP the reader is referred to the references at the end of
2.3. TEST DESIGN DOCUMENTS 49

this section.
Events can represent an arbitrary complex sequence of steps of a real-world system. An
event can be used on every level of abstraction as a programming-language independent syn-
chronization point that may trigger an associated sequence of steps. For example, an event
create process can represent the function call create process() which may include to de-
termine beforehand the possible parameter values in order to perform the function call within
its defined range of normal behavior. In contrast, the event return value ok can denote
that the return value is as expected (without stating the return value explicitly). A pro-
cess can then use these events to represent a sequence of steps that first trigger the func-
tion call and then check the return value, e.g., process CHECK CREATE can be defined as
CHECK CREATE = create process -> return value ok -> SKIP.
To specify the interface between interacting processes explicitly and to define the set of possi-
ble communication events, channels are defined.2 A channel declares either a simple, unstruc-
tured signal (e.g., channel return value ok as described above) or a structured data item. In
general, structured channels have a common prefix (the channel name) and a sequence of data
components where each is a set of values or a pre-defined data type. For example, channel
create process : {1..10} can be used to trigger the creation of specific processes, e.g., the event
create process.10 can denote the function call create process(10). To improve readability of
the CSP specifications, it is additionally possible to distinct (syntactically) between events pro-
duced by another process (i.e., input to the respective process) and events generated by respective
process (output event). For example, the above used process CHECK CREATE can be enhanced by
using structured events and by explicitly stating which events are considered as input or out-
put. Thus CHECK CREATE = create process!10 -> return value ok?10 -> SKIP means that an
event create process.10 is generated and then it is expected that another process generates the
event return value ok.10. Further details are provided in Appendix A.2.
The system modeled by the CSP specification is typically composed of different process. This
modular approach helps to write compact and reusable specifications. The processes are com-
posed by CSP operators which include operators for modeling sequences of events, branching,
loops, concurrency, parallelism, and abstraction of certain events. The operators are described in
Appendix A.
CSP is typically used to write specifications on an abstract level (which is often called design or
high-level specification) and – later on in the development process – on a more detailed level closer
to implementation. The model-checker tool FDR can then be used to reason about the different
specifications, e.g., to check for deadlocks and lifelocks or to examine if the detailed specification
is a refinement of the less detailed specification. Moreover, CSP test specifications can be used
for testing using the test system RT-Tester. Further details about the RT-Tester are provided in
Sect. 5.4.2.1.
CSP – as considered so far – is an untimed formalism. Timed CSP is the extension of CSP neces-
sary to deal with real-time aspects. The language is extended by adding timing related operators:
a timeout operator, a delay operator, and a timed prefix. As shown by [Mey01], Timed CSP pro-
cesses can be structurally decomposed into three parts: an “untimed” CSP part, simple (mutually
independent) timer processes, and auxiliary events for synchronization between the “untimed”
CSP processes and the timer processes. The test system RT-Tester uses such decomposed Timed
CSP specifications and provides internally timer processes (realized by operating system timers).
Examples of these “untimed” CSP specifications with timer events are provided in Sect. 6.4.
The main drawback of using CSP to model large systems is that tools have to deal with the state
explosion problem that occurs when the CSP specification is internally transformed into a transi-
tion system and the model-checking or test tools cannot cope with too many states. The problem
can be reduced by considering the effects of a particular channel or process definition and by tun-

2
Note that this explicit declaration is especially important for tools like FDR that aim to reason about the state space
of a process. The set of possible events is intrinsic in formal CSP specifications as used by [Hoa85].
50 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

ing the CSP specifications appropriately. Some ways are described in [FDR], p. 34–36. Others
solutions are introduced in Sect. 6.2 when describing the CSP types and channel concept for the
automated test suited described in Chap. 6. Sect. 8.1 summarizes the occurred problems and the
chosen solutions.

HybridUML. HybridUML is a UML 2.0 profile and thus can use the syntactic framework of
UML which contains well-accepted graphical constructs and different approaches for textual rep-
resentations. HybridUML separates structural concerns from behavioral aspects: Structure and
architecture are represented by class diagrams and composite structure diagrams and behavior by
statechart diagrams. Furthermore, HybridUML extends UML 2.0 by providing means to specify
time-discrete and time-continuous behavior. Inherent to UML and thus also to HybridUML are
the concepts for hierarchy, parallelism and separation of concerns. The formal semantics is de-
fined by a formal transformation into an executable system conforming to the Hybrid Low-Level
Framework. A HybridUML statechart is depicted in Fig. 2.4.

2.3.2.4 Example Comparing Different Specification Techniques

This section elaborates on the differences of informal and formal specification techniques using an
example specification which defines the process mode transition model, i.e., the operating modes
of an ARINC 653 process and when, why and how operating modes are changed. The example
consist of following parts:

1. the original specification as provided by [ARINC653] (p. 10–11),

2. the enhancements of this specification as provided by [ARINC653P1] (p. 19–22),

3. a HybridUML statechart diagram depicting the same information, and

4. a brief comparison of the three specifications and their pros and cons.

Original Specification ([ARINC653], p. 10–11). The standard ARINC 653 [ARINC653] pro-
vides the API of an operating system to be used for IMA platforms. For describing the entities,
their behavior and the requirements, [ARINC653] uses informal natural language descriptions and
graphical depictions as well as pseudo code fragments.
The internal processing entities of each partition are processes that are created by a special ini-
tialization process and which perform different API calls during the normal operating mode. For
describing the transitions from one to another operating mode, [ARINC653] uses a graphical de-
piction of the modes and the possible transitions in a statechart-like figure and an informal natural
language description. The depiction is provided in Fig. 2.2. The accompanying description (see
[ARINC653], p. 10–11) is as follows:

Process States
The process states as viewed by the O/S are as follows:

a. Dormant - ineligible to receive resources. A process is in the dormant state before it is


started and after it is terminated (or stopped).
b. Ready - eligible for scheduling. A process is in the ready state if it is able to be executed.
c. Running - currently executing on the processor. A process is in the running state if it is
the current process in execution. Only one process can be executing at any time.
d. Waiting - not allowed to receive resources until a particular event occurs. A process is
in the waiting state if it is:
- waiting on a delay,
2.3. TEST DESIGN DOCUMENTS 51

dormant

ready waiting

running

Figure 2.2: Change between process states according to [ARINC653], p. 11

- or waiting on a semaphore,
- or waiting on a period,
- or waiting on an event,
- or waiting on a message,
- and/or suspended (waiting for a resume)

State Transitions
State transitions occur as follows:

a. Dormant - Ready, when the process is started by another process within the partition.
b. Ready - Dormant, when the process is stopped by another process within the partition.
c. Ready - Running, when the process is selected for execution.
d. Ready - Waiting, when the process is suspended by another process within the partition.
e. Running - Dormant, when the process stops itself.
f. Running - Ready, when the process waits on a TIMED DELAY of zero or is preempted
by another process within the partition.
g. Running - Waiting, when the process suspends itself, and also when the process attempts
to access a resource (delay, semaphore, period, event, message) which is not currently
available and the process accepts to wait.
h. Waiting - Ready, when the process is resumed, or the resource the process was waiting
for becomes available or the time-out expires.
i. Waiting - Dormant, when the process is stopped by another process within the partition.
j. Waiting - Waiting, when a process already waiting to access a resource (delay,
semaphore, period, event, message) is suspended. Also when a process which is both
waiting to access a resource and is suspended, is either resumed, or the resource be-
comes available, or the time-out expires.

State transitions may occur automatically as a result of certain APEX services called by the
application software to perform its processing. They may also occur as a consequence of
normal O/S processing due to time-outs, faults, etc.

Enhanced Specification ([ARINC653P1], p. 19–22). In 2003, the previous ARINC 653 stan-
dard [ARINC653] has been updated by [ARINC653P1] which included some minor correc-
tions and enhancements. In general, [ARINC653P1] still uses natural language descriptions and
statechart-like figures as shown in the previous paragraph. Regarding the description of the op-
erating mode transition model, an additional figure describes the relation of the partition mode
transitions and the process’ operating mode transitions. Furthermore, this new depiction that is
52 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

provided in Fig. 2.3 has numbered transition labels which helps to find the related description part.
Apart from that, the description style and the specification formalism has not been changed (and
thus is not provided here in more detail).

COLD START or WARM START mode NORMAL mode


(9c)

waiting ready (8)

(11a)
create (1) (5)
a process
(10)
(2) (6)
dormant dormant running
(12) (3b) (4)
(11b)
(9b)
(10)
(7)
waiting
(9a)

Figure 2.3: Enhancement of Fig. 2.2 by considering also the different partition modes
COLD START/WARM START and NORMAL (figure according to [ARINC653P1], p. 20)

HybridUML Specification. When the API of the ARINC 653 operating system is defined by
HybridUML, class diagrams, composite structure diagrams and statechart diagrams are generated
that form together a complete, consistent and unambiguous specification of the structure and be-
havior. In particular, the model contains an agent process that has an accompanying statechart
diagram. The statechart diagram is depicted in Fig. 2.4 and defines the mode changes of a partic-
ular process with the process ID PID and also takes into consideration the partition mode changes.
Process mode changes (i.e., transitions in this statechart) are triggered

• by the process running in initialization mode when calling SET PARTITION MODE (NORMAL)
which results in a partition mode change,

• by other processes calling API services resulting in a state change of process PID (e.g., by
starting it using START(PID)),

• by the scheduler preempting and scheduling the process and when reporting that a resource
that has been waited for becomes available (e.g., if a message has arrived for a port),

• by the process itself trying to access a resource (e.g., a queuing port message) by using a
blocking API call (e.g., by calling RECEIVE QUEUING MESSAGE with a time out greater than
zero) or by calling STOP SELF, SUSPEND SELF, or TIMED WAIT(0), or

• when the time out of a blocking API call expires.

The transition labels reflect these different causes by different types of labels which conform to
the allowed label syntax event [guard] / action :

• labels containing only events denote API calls and other incidents triggered by other pro-
cesses, e.g., RESUME(PID),

• labels with actions only are used for API calls triggered by the process itself, for example,
/ SUSPEND SELF,
2.3. TEST DESIGN DOCUMENTS 53

• labels consisting of a guard only are used for time outs (e.g., [ t=0 ] and to remember API
calls in the initialization mode (e.g., [ not(initStarted) ]), and

• labels with combinations of events and actions are used if an external API call triggers the
transition and also an action occurs, e.g., START(PID) / initStarted=true.

Further details about the syntax and semantics of HybridUML are provided by the referenced
papers.

statemachine process (PID: Integer)

Normal Mode
Init Mode [ initStarted and
initSuspended ]
/ initStarted=false;
/ initSuspended=false [ not(initStarted) ] dormant STOP(PID)

dormant waiting
RESUME(PID)
SET PARTITION MODE START(PID) / STOP SELF waitingWhileSuspended
START(PID)
/ initStarted=true (NORMAL) STOP(PID)

x suspend
STOP(PID)
[t=0] resource available
/ initStarted=false
e suspend
ready SUSPEND(PID)
waitingForResourceWhileSuspended
waiting [ inv: t > 0 ]
[ initStarted and / SUSPEND SELF [ flow: t˙ = −1 ]
not(initSuspended) ] resource available
RESUME(PID) SUSPEND(PID)
SUSPEND(PID) [t=0]
/ initSuspended=true
xresource waitingForResource
schedule(PID) [ inv: t > 0 ]
[ flow: t˙ = −1 ]

/ TIMED WAIT(0)
eresource
running
preempt(PID) / access resource(delay);
t=delay

Figure 2.4: HybridUML statechart diagram depicting the process states and transitions considering
also the different modes of the respective partition (API services stand out in typewriter font)

Comparison. All specifications reviewed in the previous paragraphs define the possible process
states and state transitions, i.e., more or less the same information. The main difference are:

• clearness and unambiguity:


Specifications using natural language descriptions cannot be unambiguous and are –
in this particular example – difficult to understand (see for example the description
for transition waiting - waiting). Furthermore, the assignment of the textual de-
scription and the figures is often unclear as shown above for [ARINC653], but can
be improved by numbering the transitions as done in [ARINC653P1] (see Fig. 2.3).
In addition, the particular specifications in [ARINC653] and [ARINC653P1] do not
name the API services but use textual transcriptions. For example, [ARINC653P1]
contains the description “(1) dormant - ready: When the process is started by
another process while the partition is in NORMAL mode.” ([ARINC653P1], p. 21).
The HybridUML specification instead uses a transition from mode dormant to ready (both
in partition mode Normal Mode) and the label START(PID) references the API call explicitly.

• completeness of the specification:


The [ARINC653] specification does not consider the relation to the partition’s mode which
is addressed by the other two.

• test case selection approaches:


The specifications in [ARINC653] and [ARINC653P1] cannot be used for automated test
54 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

case selection. To overcome this drawback, ARINC 653 has been split into three parts3
and dedicated the part 3 to define test cases and test procedures for a conformance test
suite of the ARINC 653 API services (again using structured natural language). In contrast,
HybridUML has a well-defined syntax and formal semantics and thus it is possible to have
automated approaches for defining the test cases and test data for automated test execution
(see [BBHP04]). In addition, a simulation environment is available for HybridUML models
that allows simulated execution of the specification (see also [Bis05]).

References
The description of strategies for test case and test procedure selection is based, among others, on
[SL03] (p. 104-146) and [Sto96] (p. 325ff). The pros and cons of the different specification tech-
niques are addressed in various publications: [Sto96] addresses at a general level the advantages
and problems of using informal, semi-formal and formal specification techniques. Testing using
formal specifications is also discussed, for example, in [Pel02a].
The fundamentals of the various specification techniques addressed in this section can be found in
the following references (this list of references naturally cannot be exhaustive): CSP has been in-
troduced in [Hoa85] and a description of the formal semantics can be found in [Ros98] and [DS04],
among others. The semantics of Timed CSP is addressed, for example, in [Sch95] and [Mey01].
Testing with CSP is discussed in [PAD+ 98], [Mey01], [DS04], among others. The specification of
the Unified Modeling Language (UML) as well as various references can be found at [UML]. Ref-
erences for the precise UML approach are compiled at [pUML]. The fundamentals of HybridUML
are addressed, for example, in [BBHP03], [BBHP04], and [Bis05]. The usage of semi-formal
virtual reality environments for specifying test cases is discussed in [BT02b] and [BT02a]. An
introduction to TTCN-3 is provided, for example, in [GHR+ 03]. Statecharts as a mean to provide
hierarchical state machines for discrete systems were introduced in [Har87] and [HPSS87]. The
STATEMATE semantics of statecharts can be found in [HN96] and [DJHP98], among others. A
(slightly outdated) survey comparing the different statechart semantics is provided in [vdB94].
Other formalisms that can be used for specifying real-time systems include (but are not lim-
ited to) the Z notation (e.g., [Spi92], [DW96]), timed automata (e.g., [LV92], [AD94], [CO00]),
the duration calculus (e.g., [ZRH93], [Rav95]), hybrid automata (e.g., [ACH+ 95], [Hen96]), and
CHARON (e.g., [AGLS01], [ADE+ 01]). Various model checking techniques and tools are also
discussed in [BBF+ 01].

2.4 Test Data Generation, Test Execution and Test Evaluation

As described in the previous section, test design documents compile test cases and test procedures
which can be defined using different specification formalisms – informal ones as well as formal
specification techniques. One part of the test procedures – the test specifications – define the in-
puts to the SUT, the expected outputs and the timing requirements. Since the test specifications
may be written in specification techniques which cannot be executed by appropriate test tools or
the test procedure may not contain the necessary tool-related configuration files, it is often neces-
sary to produce so-called implemented test procedures that contain executable test specifications
and the required configuration data. For the following discussion about approaches for test data
generation, test execution and test evaluation, we will consider only the test specifications and dis-
regard the specific configuration data. Test specifications – in particular test specifications using
(semi-)formal specification techniques – can be script-based or specification-based. A script-based
test specifications is typically one specific sequence of inputs to and outputs from the SUT, i.e.,
3
ARINC 653 part 1 [ARINC653P1-2] focuses on the required services (and is a revised version of [ARINC653P1]),
ARINC 653 part 2 [ARINC653P2] describes the extended services, and ARINC 653 part 3 [ARINC653P3] defines a
conformity test specification.
2.4. TEST DATA GENERATION, TEST EXECUTION AND TEST EVALUATION 55

when executing this specification each time the same sequence of test inputs is executed and ex-
actly one sequence of outputs from the SUT are expected (typically without allowing that outputs
come within a time interval). A specification-based test specification uses a specification that al-
lows variation of inputs and outputs by defining branching and considering different sequences of
outputs (which are all legal). Furthermore, specification-based test specifications usually define
allowed time intervals in which the outputs are expected to occur. Since such specifications usu-
ally allow different sequences of inputs to the SUT, a test data generation algorithm has to generate
all or a subset of possible sequences.
Generally speaking, three forms of test data generation, test execution and test evaluation can be
distinguished: manual, automated and semi-automated. When using automated approaches test
data generation and test evaluation can be performed on-the-fly, i.e., during testing, and offline,
i.e., before and after test execution, respectively. The following table (Table 2.1) summarizes
briefly how these characteristics are related to the type of test specification provided by the test
procedure and implemented test procedure. The details are discussed thereafter in Sect. 2.4.1 with
respect to test data generation, Sect. 2.4.2 regarding test execution, and Sect. 2.4.3 considering
test evaluation and error diagnosis. Note that implemented test procedures using an informal
test specification technique are usually based on test procedures using informal test specifications
whereas implemented test procedures using semi-formal and formal methods can be derived from
all kinds of test procedure specifications.

Test Implemented Test Data Test Execution Test Evaluation


Procedure Test Generation
Procedure

informal inherent manual manual

informal semi-formal
semi-formal formal
formal
script-based inherent automated
semi-automated
(manual) automated
semi-automated
specification- automated automated
based semi-automated

Table 2.1: Relation of test data generation, test execution and test evaluation to the provided test
specifications

2.4.1 Test Data Generation

Test data generation is the process that determines the sequence of inputs to the SUT and the exact
delay between two inputs.
In informal and script-based test specifications, the test inputs and their sequence are described
explicitly. Although informal specifications can provide branching, it is often avoided or expanded
explicitly in the test specification of the implemented test procedure. Since only one sequence
of inputs is defined, there is no possibility to adapt it on-the-fly while executing the test. As a
consequence, the script execution often aborts if the SUT reacts with an unexpected output which
may be perfectly legal but just not admitted as the next step of the script. Furthermore, it has to
be considered that the length of a script growth linearly with the length of the execution to be
performed which may result in unreadable specifications.
56 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

For specification-based test specifications it is necessary to generate the sequence of test inputs
for the SUT either dynamically during the test execution (i.e., on-the-fly or online) or beforehand
(i.e., offline). On-the-fly approaches have the advantage that they can select the inputs depending
on the preceeding SUT outputs. In contrast, offline test data generation generates all or a subset of
possible sequences in advance and thus cannot react to any occurring non-determinism in the SUT
(e.g., caused by internal scheduling in the SUT which may result in minor changes of the sequence
of outputs or their timing). There are also approaches that use offline techniques to restrict the test
specification according to a particular test purpose and then use the resulting smaller specification
for on-the-fly test data generation.
However, the drawback of on-the-fly test data generation approaches is that they have to be ex-
ecuted intertwined with the test driver which is responsible for communication with the SUT.
Consequently, for execution in (hard) real-time both the test driver and the test data generation
algorithm have to meet hard real-time constraints.

2.4.2 Test Execution

Test execution is the actual execution of an implemented test procedure (which is equal or derived
from a test procedure contained in the test design document).
If the implemented test procedure contains informal test specifications, it is inherent that it is not
possible to have a test tool supporting the test execution. Instead, it is necessary to perform manual
steps for configuring the SUT and the environment and for executing the informal test specifica-
tion. For manual test execution, the test inputs are provided manually to the interfaces of the SUT,
for example, by pressing buttons, changing the switch position, cutting cables, or changing the
SUT environment (e.g., temperature, pressure). The outputs of the SUT are observed by manu-
ally reading the measurement instruments which can also be small lamps. For the test report, the
tester usually has to log manually the given test inputs, the observed outputs and the respective
time stamps. Inherent to manual test execution is that giving inputs, observing outputs and giving
new inputs cannot be performed in hard real-time and thus cannot be used for testing reactive hard
real-time systems (assuming that reactions are expected within few seconds or milliseconds).
Script-based test specifications in an implemented test procedure allow manual test execution as
described in the previous paragraph but can also allow or require automated or semi-automated test
execution. Automated test execution means that the test inputs determined by test data generation
(see previous section) are physically sent to the corresponding interface of the SUT and the outputs
of the SUT are observed automatically. Typically, this includes that the test driver transforms
the abstract specification events into concrete interface signals before sending them to the SUT
interface and vice versa. Thereby, all events are logged with their time stamp. If required by the
test environment, it is sometimes necessary to perform some steps manually which are typically
only those that have no hard real-time constraints. This semi-automated test execution can thus
make profit of the real-time test execution and, simultaneously, cope with the deficiencies of the
test environment that requires the manual steps.
Implemented test procedures containing specification-based test specifications are made for auto-
mated or semi-automated test execution, i.e., usually the objective to automate test execution is
the cause for writing such elaborated test specifications. If the test data have been generated in
advance using an offline approach, the test driver for specification-based and script-based testing
do not differ. In contrast, if the test driver is combined with an on-the-fly test data generator, both
have to cooperate in real-time.
In general, automated test execution needs a test system or test tool running on a test engine. Dif-
ferent test systems are available supporting different specification techniques. [Pel03] and [Mey01]
(p. 19ff) provide a list of references to papers about test automation tools based on formal methods.
2.4. TEST DATA GENERATION, TEST EXECUTION AND TEST EVALUATION 57

In this thesis, we will focus on test specifications written in CSP (with a special timing-related se-
mantics for the timer control events) and test automation using the test system RT-Tester. This test
tool provides means for on-the-fly test data generation, automated test execution and on-the-fly
test evaluation. The RT-Tester is introduced in Sect. 5.4.2.1.
The test engine is the platform for running the test system and providing the physical connection
to the interfaces of the SUT. In order to allow hard real-time execution of on-the-fly test data
generation algorithms and test drivers, it has to supply an appropriate operating system and com-
puting hardware. An example of a test engine and the requirements for testing an IMA platform
are discussed in Sect. 5.4.1.
In addition to the test system, further tools can be required to prepare or configure the SUT as
required by the test procedure, e.g., to load the correct configuration. As the pace of integration
testing increases, interoperability of these special tools and the testing tools and the overall testing
process is significant. In particular, limitations with respect to interoperability or automation have
a major impact on the overall test process. Interoperability can often be established by intermediate
tools or scripts. Nevertheless, if such tools miss a command line interface for automation, it is not
possible to fully automate the testing process and manual steps are required instead. This increases
the overall costs and time for test execution since manual steps are less effective. Section 6.5.1
and Sect. 6.5.2 discusses the tool environment for testing an IMA platform.

2.4.3 Test Evaluation and Error Diagnosis

Test evaluation checks the correct sequence and timing of outputs from the SUT with respect to
the given inputs and the intended behavior. It can be performed during the test execution, with
a small delay or afterwards. Checking the correctness while the test is performed allows to stop
the test execution in case of errors. This permits that test runs with errors in the beginning can
be stopped, analyzed and corrected, and then restarted. Nevertheless, not all unexpected outputs
from the SUT are errors by default, but can also show that the test specifications impose too many
restrictions, e.g., by not allowing minor deviations with respect to time.
For informal test specifications, the test evaluation is typically performed manually based on the
manually written test logs of the tester who has executed the test. If test execution and test evalu-
ation is performed by the tester, on-the-fly test evaluation is also possible to some extent.
Semi-formal and formal test specifications with adequate tool support usually allow automated
test evaluation against the specification. Depending on the expressiveness of the specification
technique, certain situations are considered errors but are allowed deviations. Thus, all automat-
ically detected erroneous situations have to be analyzed which is often performed manually by
the tester in cooperation with a domain expert (semi-automated test evaluation). Generally, most
formal specification techniques allow to have elaborate test specifications which can consider dif-
ferent correct behavioral reactions (in particular with respect to timing).
Test evaluation is affiliated with error diagnosis if deviations are detected when comparing the
test log with the expected behavior. Error diagnosis is the process of analyzing the derivation
in order to locate the cause of the error. Most faults are due to an implementation error, i.e.,
located in the system under test, but can also be located in the requirement specification or the
derived test cases and test procedures. This means that then backtracking of the errors via the
test specification to the requirement specification is necessary to locate the error. Of course, this
task is simplified if one formal specification model is used for all documents. Fault diagnosis
can also be supported by built-in test procedures that may help to exclude hardware faults (e.g.,
missing communication links). Furthermore, it is often necessary to narrow down the interfaces
contributing to fault propagation and to generate the fault tree based on the involved interfaces and
components.
58 CHAPTER 2. TESTING OF AVIONICS SYSTEMS

References
Lists of publications discussing test automation (and test automation tools) based on formal meth-
ods can be found in [Pel03] and [Mey01] (p. 19ff), among others. The usage of formal specifi-
cations (particularly CSP specifications) for automated test data generation and test evaluation is
also addressed, for example, in [PAD+ 98], [Pel02a], and [Pel02b]. Like this thesis (particularly
Chap. 6), the examples in the latter two use CSP test specifications and the test system RT-Tester
for on-the-fly test data generation, automated test execution, and on-the-fly test evaluation.
Part II

Avionics Systems using Integrated


Modular Avionics

59
Chapter 3

Introduction to IMA Platforms

This chapter elaborates on IMA platforms thereby focusing on the standardized real-time operating
system and the constraints for developing application software to be running on IMA modules.
IMA modules as considered in this thesis are so-called Core Processing and I/O Modules (CPIOM)
which provide a common computing resource and different interfaces to several applications. As
a shared resource, the IMA module can host multiple applications and each application can use
one or more partitions to perform its tasks. Partitions are conceptually the central program units
of the IMA module. They are assigned to exactly one application and have separate memory areas
and dedicated processing time slots. Furthermore, the operating system supports cooperation of
different partitions hosted on the same or different modules by providing inter-partition and inter-
module communication means. The consequence of the resource sharing (i.e., sharing of CPU
time, memory, and communication means) is that spatial and temporal partitioning has to ensure
that the applications remain functionally separated, i.e., that applications cannot interfere with
each other. This robust partitioning helps to prevent the expansion of failures from one faulty
application to another application on the same IMA module and is necessary to execute several
avionics applications of different criticality levels in parallel.

For the operating system to provide partitioning, it is necessary to define which memory part shall
be used by which partition, when each partition shall be scheduled, and which ports can be used
to communicate with others. In addition, IMA platforms shall be used for many different purposes
and shall allow efficient usage of memory and computing resources. Thus, configurability has
to be addressed to provide the necessary parameters to the operating system. This means that
each application determines their demands on the IMA platform, i.e., the number of required
partitions, the necessary stack size, code area size, data area size, scheduling frequency, required
communication ports, etc. The system integrator then collects the configuration needs of each
application and distributes all applications of one domain across several IMA modules. In addition,
the system integrator can use different types of IMA modules which may provide different numbers
of interfaces, varying computing power, different memory size. A possible system architecture
using integrated modular avionics is described in the next chapter (Chap. 4).

In the following section (Sect. 3.1), the IMA platform architecture is introduced, i.e., the hardware
characteristics, the possible interfaces, and operating system related properties are described. It
also details which operating system services are provided to the avionics applications according
to the ARINC 653 API. Configurability of the IMA platform is considered in Sect. 3.2. When
developing avionics applications to be running in one or several partitions of one or more IMA
modules, the impact of the resource sharing and the characteristics of the operating system have
to be considered. Section 3.3 discusses some general aspects.

61
62 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

3.1 IMA Platform Architecture

The IMA platform architecture comprises the following parts:

• The application software is contained in the avionics partitions of the respective IMA mod-
ule and performs (parts of) the application program.

• The standardized ARINC 653 API of the operating system provides services to be used by
the avionics applications for performing their tasks and for communicating with others.

• The operating system manages partitions and their communication. At partition level, the
operating system manages processes within a partition. For communication, scheduling,
memory management, timing, and health monitoring, the operating system interacts with
the hardware interface system.

• The hardware interface system comprises the set of interface drivers for the contained hard-
ware interfaces and additionally provides means to access the Memory Management Unit
(MMU) and the clock.

• The hardware of an IMA module consists of the hardware interfaces (e.g., AFDX, CAN,
ARINC 429, etc.), the processor(s), the hardware clock, the MMU, and the memory.

• The configuration tables are used by the operating system and the hardware interfaces sys-
tem to configure memory access, scheduling, and communication.

Figure 3.1 depicts this platform architecture. It also shows that an application can use several
partitions to perform its tasks, e.g., one for interacting and the other one for monitoring.

Application 1 Application A
IMA Module

Avionics Partition 1 Avionics Partition 2 Avionics Partition M

Process 1 . . . Process N1 Process 1 . . . Process N2 Process 1 . . . Process N M


...
ARINC 653 API
Operating System
Configuration

HW Interface System
Tables

Hardware

AFDX ARINC 429 CAN Discrete I/O Analog I/O

Figure 3.1: IMA module architecture

The following subsections detail the hardware issues (Sect. 3.1.1) and operating system issues
(Sect. 3.1.2). The latter also addresses the operating system API, i.e., the services provided by the
operating system. The configuration tables are addressed thereafter.

3.1.1 IMA Platform Hardware

An IMA platform is a single controller providing computing and communication resources and
is therefore also called Core Processing and I/O Module (CPIOM). The hardware characteristics
of IMA platforms are not fully standardized to allow different types of IMA modules and to per-
mit technological progress without resulting in non-conforming hardware platforms. Therefore,
the number and particular types of processors, memory size, etc. are not standardized (e.g., as
3.1. IMA PLATFORM ARCHITECTURE 63

an ARINC standard). Nevertheless, the requirements on the hardware are quite stringent, e.g.,
with respect to reliability, availability and safety, and are also influenced by other factors like
power consumption, specific hardware support for temporal and spatial partitioning, and hard real-
time requirements. However, the IMA module’s connector and hardware dimensions comply with
ARINC 600 and thus ensure that IMA modules of different suppliers can easily be interchanged.

Example. For the VICTORIA project, IMA modules have been provided by different suppliers
for different domains, e.g., by Diehl Avionik Systeme for the cabin domain (see [Die04a] and
[Die04b]), by Thales Avionics for the utilities domain (see [Tha04c] and [Tha04b]), and by Smiths
for the energy domain (see [Smi04]). Each IMA module contains several boards for processing,
I/O and power supply. Common to all these IMA module types is a processor of the PowerPC
family, an internal PCI bus, and an AFDX interface to be used for inter-module communication.
The IMA module provided by Smiths is a Core Processing Module (CPM) which means that
no further interfaces are provided. The other CPIOMs provide hardware interfaces for discrete
in- and output, analog in- and output, CAN and ARINC 429 busses, and some special I/Os (for
temperature sensors) in addition to the AFDX interface.

3.1.2 IMA Operating System and the ARINC 653 API


The operating system manages the defined partitions and the processes of the partitions and pro-
vides means for communication, scheduling, and health monitoring to ensure spatial and temporal
partitioning.
The operating system operates at two levels: at module level and at partition level. At module
level, the operating system manages partitions and their inter-partition communication including
communication with external communication peers (e.g., partitions on other IMA modules or non-
IMA controllers). At partition level, the operating system manages processes within each partition
and their intra-partition (i.e., inter-process) communication. At both levels, the operating system
provides scheduling, memory and time management, and health monitoring.
The ARINC 653 standard (part 1) defines a set of functions (“services”, “system calls”) which
the operating system provides for application software to control scheduling of the partition’s pro-
cesses, to communicate with other partitions and processes, and to get status information about
the partition’s objects. Thus, the application software is decoupled from the actual hardware ar-
chitecture and hardware changes are transparent to the application software. Further benefits are
• portability which allows to use the application software also for other aircraft types (with
minimal recertification efforts),
• reusability which allows to reuse application code for other IMA applications, and
• modularity which allows to modify the overall system architecture (e.g., by moving a parti-
tion to another IMA module).
The services and their behavior are specified by using a specific pseudo code notation that de-
scribes the post conditions of the services. The interface specification is language-independent,
but an Ada and a C binding are provided in Appendix D and E of ARINC 653 part 1, respectively,
which directly define the enumerations, parameter types, and the services in a programming lan-
guage notation. In this thesis, all examples providing concrete application code use the C interface
specification.1
The ARINC 653 services are described in subsequent subsections based on [ARINC653P1 d4s2]
(which is the draft document prior to adoption of current standard document [ARINC653P1-2]).
The services are typically grouped into the following categories:
1
There are minor differences in the Ada and C interface specification due to the different handling of types and
strings but these are not considered in more detail since this thesis focuses on the C interface specification.
64 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

• partition management services

• process management services

• inter-partition management services

• intra-partition management services

• time management services

• memory management services

• health monitoring services

Almost all services provide a return code to denote successful completion of the service or the
occurrence of an error (e.g., invalid parameters, invalid parameter range, invalid parameters with
respect to the current configuration table, invalid operating mode of the partition). The allowed
return codes are defined by an enumeration type (RETURN CODE TYPE).
The aim of the following description is to provide an overview of the OS services and some of their
parameters. For detailed behavioral specifications, the reader is referred to [ARINC653P1 d4s2]
(and the current standard document [ARINC653P1-2]).

3.1.2.1 Partition Management

Partitions are defined in the configuration table and – according to the configured scheduling – ac-
tivated in fixed, deterministic cycles. This major time frame (MAF) is periodically repeated while
the module is in operational mode. Depending on the configuration, each partition has one or more
partition windows within the MAF which is each defined by its offset from the beginning of the
MAF and its duration. Thus, the partitions are activate in a predefined order and each partition has
a predetermined amount of time to access the common resources. Temporal partitioning ensures
that a partition has uninterrupted access during the assigned time periods. Each partition has also
predetermined areas of memory to be used by its processes (with segregated code and data areas).
Spatial partitioning ensures that each partition has write access to certain areas of its memory but
prohibits access to other partition’s memory. Since the individual requirements vary form appli-
cation to application, the scheduling, the memory size and the access rights are configured in the
configuration tables.
After successful initialization of the module, the partitions are in operating mode COLD START
and the respective initial processes (often called main processes) are running – one in each par-
tition. Operating mode COLD START is the initialization phase of the partition where processes
and communication objects are created by the main process as implemented by the application
programmer. After completion of the partition’s initialization tasks, the initial process can call
SET PARTITION MODE (NORMAL) to switch to the partition’s operating mode where the created (and
started) processes are scheduled. The service can also be used for restarting the partition by call-
ing SET PARTITION MODE with parameter COLD START or WARM START2 and for setting the partition
to idle (SET PARTITION MODE (IDLE)) if serious faults have been detected. Nevertheless, changing
the operating mode of one partition – in particular setting it to idle – affects only the respective
partition and the others continue as before. Also, the module’s partition scheduling remains un-
changed.
For checking the current status of the partition, the service GET PARTITION STATUS is provided
which returns some configuration parameters (e.g., partition identifier, period, duration) and status
information like the start condition and the current partition’s operating mode.
2
Operating mode WARM START is similar to COLD START and the differences depend mainly on the hardware
capabilities and system specifications.
3.1. IMA PLATFORM ARCHITECTURE 65

3.1.2.2 Process Management

Within each partition, the task to be accomplished by the application is performed by one or more
concurrently executed processes that share the computing resources, the communication ports, and
the execution time of the partition. The processes of each partition are scheduled using a priority
preemptive scheduling algorithm which supports periodic and aperiodic scheduling. Several OS
services support the accurate process control, e.g., to change the priority, to allow or prevent
rescheduling, to stop or start processes.
The attributes of the initial process are specified during linking or in the configuration tables. The
other processes are not configured in the configuration tables but created during the initialization
phase of the partition using the service CREATE PROCESS. During process creation, the stack size
and other process attributes regarding scheduling (e.g., base priority, time capacity and period) are
determined. Thereby, the value of attribute time capacity defines how long the process can run
without rescheduling which is crucial when the process is considered to have a hard deadline and
the deadline is missed. Depending on the process’ attribute ‘period’, two types of processes are
distinguished:

• Periodic processes are periodically activated as determined during process creation.

• Aperiodic processes have no period and are therefore always ready to run (if they are not
suspended or waiting for a resource or a timer).

As part of the process management, the operating system administers the attributes of each process
and evaluates their current values to determine which process has to be scheduled. This includes
the process states and the process state transitions triggered by respective API service calls (see
figures in Sect. 2.3.2.4). To get the current process status, the API service GET PROCESS STATUS
can be used. To get the process identifier (based on a process’ name or for the running process),
the services GET PROCESS ID and GET MY ID are provided.
Each process has a defined process state which changes as depicted in Fig. 2.4. However, after
being created, each process needs to be started. Typically, the processes are started during the
initialization phase when the initial process calls START for the respective process. Processes can
also be started with a delay using DELAYED START. For switching to a partition’s operating mode
NORMAL, at least one process has to be started. After switching to NORMAL mode, all started aperiodic
processes are in state READY, all started periodic processes are in state WAITING denoting that they
are waiting for their next release point, and all process that have not yet been started are in state
DORMANT until being started by one of the other processes. The active process which has been
selected by the scheduler according to its state and priority is in state RUNNING.
Processes can also stop other processes when calling STOP with the specific process ID. The re-
sulting process state is DORMANT. A process can also stop itself using STOP SELF, then the scheduler
has to select another process.
An aperiodic process can also be suspended (SUSPEND) or suspend itself (SUSPEND SELF). It then re-
mains in the resulting state WAITING until it is resumed by another process (RESUME) or the timeout
expires (for SUSPEND SELF).
The process scheduling depends on the priorities of the processes in state READY. To control
scheduling, the priority of a process can be increased or decreased using SET PRIORITY. As a
consequence, the currently running process can be preempted if it has set the priority of another
process higher than its own. To avoid this preemption, the process can disable process reschedul-
ing for the partition using LOCK PREEMPTION. Each call of LOCK PREEMPTION increases the lock
level. After accessing the critical sections or resources, the process should enable rescheduling by
calling UNLOCK PREEMPTION (until the lock level becomes zero).
66 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

3.1.2.3 Communication

For interaction between applications and their equipment, the operating system provides means
for communication with external communication peers which is often referred to as inter-partition
communication. For partition-internal communication between processes and their synchroniza-
tion, the operating system offers appropriate services called intra-partition communication ser-
vices. These groups of communication services are described in the following.

Inter-partition Communication. The processes of a partition can communicate with the pro-
cesses of other partitions on the same module (intra-module or inter-partition communication) as
well as with processes of partitions hosted by other IMA modules, with other non-IMA controllers,
or with peripheral equipment (inter-module or external communication). For all inter-module
communication, the operating system interacts with the respective interface drivers to send or re-
ceive messages. For inter-partition communication the operating system manages the respective
memory areas that are mapped to the communication ports. Nevertheless, the operating system
does not distinguish inter-module and inter-partition communication but provides a unified access
mechanism.
The partitions (or, more precisely, their processes) communicate using messages which are sent
and received using the services provided by the OS. A unified port concept supports portability of
the applications by mapping the ports internally to the interface channels. Thus, the I/O interfaces
used for inter-partition communication are transparent for the application and only determined in
the configuration table. As a consequence, the messages at the API level contain only the payload
(i.e., the data to be transmitted) and do not contain routing information like sender and receiver. If
this information is requested by a specific application, an application-level protocol has to ensure
that the sender attaches this information.3
Each port can either be used for sending or receiving (port direction SOURCE or DESTINATION,
respectively). Ports are also distinguished according to the transfer mode:

• Sampling ports are used for communicating continuously varying signals which are trans-
mitted periodically when loss of single or a few messages is acceptable.

• Queuing ports are chosen for transmitting irregular events that may occur at random inter-
vals (e.g., the change of a discrete value).

The information concerning source and destination of a communication link, the physical com-
munication medium (e.g., AFDX, CAN), the transfer mode (i.e., sampling or queuing mode), the
maximum message size, queue length (for queuing ports), etc. are determined in the configuration
tables.
Figure 3.2 depicts an IMA module with several partitions. Partition 1 has three queuing ports:
one for receiving AFDX messages, one for sending AFDX messages, and one for communicating
with partition M. Since partition M is hosted on the same IMA module, the messages are routed
internally which is transparent to the partition’s processes. Partition M has one queuing port for
receiving messages from partition 1, and two sampling ports – one for analog input and one for
analog output.
The communication ports have to be created during partition initialization using the services
CREATE SAMPLING PORT (for sampling ports) or CREATE QUEUING PORT (for queuing ports) which
returns a port identifier for each port to be used by subsequent API calls. Port creation allo-
cates no further memory since all memory needed for communication management has already
3
An example for such an application-level protocol is the communication protocol between test applications and
test specifications which is described in Sect. 6.1.2.
3.1. IMA PLATFORM ARCHITECTURE 67

IMA Module Avionics Partition 1 Avionics Partition M


Process 1 . . . Process N1 Process 1 . . . Process N M
...
QP QP SP
ARINC 653 API QP QP SP

Configuration
Operating System

HW Interface Tables
System

Hardware
AFDX ARINC 429 CAN Discrete I/O Analog I/O

Figure 3.2: IMA module with inter-partition and I/O communication using queuing and sampling
ports

been accounted at configuration time. For sending messages to the configured communication
partner, WRITE SAMPLING MESSAGE and SEND QUEUING MESSAGE, respectively, are called with the
message as one of the parameters. The operating system then checks that all parameters are
valid (and that the queue of the queuing port is not yet full). For sampling ports, the previous
message is overwritten. For queuing ports, the new message is appended to the message queue.
The messages can then be received using READ SAMPLING MESSAGE and RECEIVE QUEUING MESSAGE,
respectively. The operating system also provides services to get status information about the
port (GET SAMPLING PORT STATUS and GET QUEUING PORT STATUS, respectively), and to get the port
identifier (GET SAMPLING PORT ID and GET QUEUING PORT ID, respectively).

Intra-partition Communication. To reduce the overhead of inter-partition communication ser-


vices when used for intra-partition communication, the operating system provides means for gen-
eral inter-process communication and synchronization (buffers and blackboards) and means for
inter-process synchronization (semaphores and events).
Intra-partition communication objects are created during initialization phase using the provided
API services (CREATE BUFFER, CREATE BLACKBOARD, CREATE SEMAPHORE, and CREATE EVENT). The
objects are not predefined in the configuration tables, but the amount of memory required for
management of intra-partition communication objects is allocated from the partition’s memory
(which is defined in the configuration table), i.e., as many objects can be created as supported by
the pre-allocated memory space.
Buffers and blackboards are the equivalent to queuing and sampling ports, respectively, but have no
direction and thus can be used for writing and reading. This is depicted in Fig. 3.3. The respective
API services are SEND BUFFER (for writing into the buffer), RECEIVE BUFFER (for reading from
the buffer), DISPLAY BLACKBOARD (for overwriting the previous message), READ BLACKBOARD (for
reading the current blackboard message), and CLEAR BLACKBOARD (for emptying the blackboard).
Additionally, GET BUFFER STATUS and GET BLACKBOARD STATUS are provided for getting the current
status, and GET BUFFER ID and GET BLACKBOARD ID for getting the respective object ID.
Semaphores are used to control access to the partition’s resources. The OS provides the ser-
vices WAIT SEMAPHORE (to request access to the resource), SIGNAL SEMAPHORE (to signal its end
or to denote that the resource is available), GET SEMAPHORE ID (to get the semaphore ID), and
GET SEMAPHORE STATUS (to get the semaphore’s current status).
Events are used for synchronization between processes by notifying the occurrence of a specific
condition (SET EVENT) to those processes which explicitly waited for the event (WAIT EVENT). For
resetting the event, RESET EVENT can be used. The current status of the event and its event ID are
returned from GET EVENT STATUS and GET EVENT ID, respectively.
68 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

IMA Module Avionics Partition 1 Avionics Partition M


Process 1 . . . Process N1 Process 1 . . . Process N M
...

ARINC 653 API

Configuration
Operating System

HW Interface Tables
System

Hardware
AFDX ARINC 429 CAN Discrete I/O Analog I/O

Figure 3.3: IMA module with intra-partition communication

3.1.2.4 Time Management

Each IMA module has a single clock which is used by the operating system for scheduling and for
treating deadlines or timeouts. The notion of time is local to a module. A global network time has
to be received separately.
For the processes, the operating system provides services to get the current local time (GET TIME)
and to wait until a timer expires (TIMED WAIT). Additionally, a periodic process can suspend its
execution until the next release point using PERIODIC WAIT which also postpones its deadline and
avoids deadline violations. An aperiodic process can update its deadline with a specific amount of
time provided as a parameter to the service REPLENISH.

3.1.2.5 Memory Management

All memory areas of the partitions are defined in the configuration tables, and allocation of addi-
tional memory is not possible nor supported at runtime. In the configuration tables, memory areas
for stack, code, and data are reserved for each partition which are shared by all processes and
communication objects (e.g., buffers) of the respective partition. In the initialization phase, when
all processes and communication objects are created, each one gets its specific memory space (as
requested by the attributes of the specific object) which remains reserved for the particular object
until re-initialization of the partition. Thus, there is no need for specific memory management or
memory allocation services.
Furthermore, the memory ares of the partitions are not accessible by processes of other partitions
which is checked by the Memory Management Unit (MMU). Any memory violation is detected
by the Health Monitoring.

3.1.2.6 Health Monitoring

The operating system provides mechanisms for common maintenance including (a) monitoring
and reporting of hardware, application and OS software faults and failures, (b) fault isolation
mechanisms, and (c) prevention of fault propagation. For detecting errors, the health monitoring
service uses the Built-In Tests (BIT) and the Built-In Test Equipment (BITE) provided by the
platform’s hardware and hardware interface system.
Errors may occur at module, partition or process level. Module-level errors are, for example, con-
figuration errors, module initialization errors, or errors caused by OS-internal functions. Partition-
level errors include partition configuration errors, partition initialization errors, and errors during
3.1. IMA PLATFORM ARCHITECTURE 69

process management as well as errors occurring while the error handler process is running. Typi-
cal process-level errors are application errors (raised explicitly by one of the processes), illegal OS
service requests, and process execution errors (e.g., overflow, memory violation, numeric errors).
Fault responses depend on the error level: For module- and partition-level errors, the fault re-
sponses are configured in configuration tables once for the module-level errors and per partition
for the partition-level errors. At process level, the fault responses can be specified by a special
highest-priority process called error handler process. The error handler can identify the error and
the faulty process and then take recovery actions at process level (e.g., stop or start processes) or
at partition level (e.g., restart partition, stop partition). The error handler has to be created during
the partition’s initialization phase using the OS service CREATE ERROR HANDLER. If no error handler
is created, recovery actions are taken at partition level.
The error handler (if created) is activated only during operating mode NORMAL. During partition
initialization (even after the creation of the error handler) and for errors occurring while the error
handler is active, partition-level recovery mechanisms are performed as configured.
The OS provides the following services: If a process wants to invoke the error handler, it can
use RAISE APPLICATION ERROR with the specific error code APPLICATION ERROR and an error mes-
sage as parameter. This starts the error handler of the partition (if created) which can then take
the recovery actions.4 Therefore, it can call GET ERROR STATUS to determine the error code, the
identifier of the faulty process, and the associated error message. If a process or the error handler
process need to report erroneous behavior to be logged by the health monitoring function, it can
use REPORT APPLICATION MESSAGE.

3.1.2.7 Operating Modes of IMA Modules

ARINC 653 focuses on the interface between OS and application software and does not consider
the operating modes of the module. During module initialization, i.e., after a power on or after a
hardware reset, the IMA module’s core operating system software performs some basic checks

• to retrieve the current status of the IMA module (e.g., on ground, during flight),

• to check which software has already been loaded (i.e., is the OS software already loaded,
have the application software and the configuration tables been loaded), and

• to ensure that the IMA hardware, the operating system software, the configuration tables,
and the application software are compatible.

Depending on the results of these checks, the core OS software allows, requires, or denies loading
of software and determines the next operating mode:

• If parts of the required software have not yet been loaded but all other tests have been
successful, the module remains in a passive mode which allows uploading of data.5

• In case of any errors or serious problems, the IMA module is completely deactivated, i.e.,
halted.

• If all checks have been successful and OS software, configuration tables, and the software
of the different applications have already been loaded, the module is in so-called operational
mode. The operating system then starts the scheduling of the configured partitions and each
running partition performs its initialization tasks.
4
Note that recovery actions do not include correction of errors, e.g., limiting a value in case of overflow. In such
cases, the possible actions are stopping and restarting of the faulty process and restarting or deactivating the respective
partition.
5
The protocol for aircraft data loading is defined by ARINC 615A.
70 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

References
IMA platforms (i.e., CPIOMs and CPMs) as used within the VICTORIA project are described, for
example, in [Die04a], [Die04b], [Tha04c], [Tha04b], and [Smi04].
The ARINC 653 API of the IMA operating system was first published in 1997 ([ARINC653])
and updated in 2003 ([ARINC653P1]). At this time, it was also decided to extend the ARINC
653 specification and split it into three parts: Part 1 describes the required services (i.e., all
services already covered in the first standard), part 2 introduces optional extended services,
and part 3 specifies procedures for conformity testing. The current standard documents are
[ARINC653P1-2], [ARINC653P2] and [ARINC653P3]. The descriptions in this thesis are based
on [ARINC653P1 d4s2] which is the draft document prior to adoption of [ARINC653P1-2].

3.2 Configurability of IMA Platforms

IMA modules are environments that allow full portability and reuse of applications by providing,
on the one hand, an API that abstracts from hardware implementation details and, on the other
hand, means for configuring the IMA module according to the functional requirements of the
applications and according to the safety requirements of the system. The aim of the configurability
is

• to provide flexibility for a large number of potential applications,

• to provide the OS with the information necessary for integrity checking during module
initialization and for ensuring spatial and temporal partitioning, and

• to allow additionally that the available resources (i.e., processing time, memory, and com-
munication interfaces) are efficiently shared between the partitions.

However, it is evident that the module’s configuration has to be consistent and complete. The
system integrator is responsible for the configurations of all modules of the system. This means,
the system integrator has to ensure that

• the requirements of each application are fulfilled,

• the partitions hosted by a specific module are (in sum) consistent with the hardware proper-
ties of the module (e.g., do not need more interfaces than provided),

• scheduling, memory assignments, and communication ports for each IMA module’s config-
uration are consistent and complete,

• the correct routing of messages and signals between partitions on the same IMA module,
between different modules, and to/from other controllers or equipment are correct and com-
plete, and

• the architectural requirements with respect to redundancy and selected communication tech-
niques are considered adequately.

The role of the system integrator is usually performed by the airframer who is responsible for the
various domains and the complete system.
The system integrator compiles the configuration data by collecting the requirements of the appli-
cations and capturing their communication partners. Then, the partitions of each application are
assigned to the IMA modules of the respective domain by considering the partition’s requirements
(memory needs, scheduling period and duration, etc.), the redundancy requirements with respect
to the system architecture and the criticality level of the applications, and the safety requirements
3.2. CONFIGURABILITY OF IMA PLATFORMS 71

of the aircraft. The distribution can be optimized, for example, by increasing the efficient usage
of modules (with respect to memory or scheduling) to reduce the number of required modules,
by maximizing intra-module communication, or by distributing applications of high criticality
to different modules. Moreover, the system integrator can provide spare memory and execution
time for each partition or in each module to prevent that configuration requirement changes of
one application have a global effect. The result of the distribution process are configurations for
each module and routing tables which specify the inter-module communication and can be used
to configure switches or other intermediate nodes. Appropriate tools can support the system in-
tegrator in checking for consistency and completeness or can provide means to detect and mark
inconsistencies during data capturing.
For representing the configuration data, different formats are possible for defining the structure
of the configuration data: a XML schema (see e.g., [ARINC653P1 d4s2], p. 100–102), a class
diagram (e.g., like the XML schema relationship class diagram in [ARINC653P1 d4s2], p. 101), a
table format (e.g., as an Excel table), an ASCII representation of such tables (e.g., comma or semi-
colon separated value (CSV) tables), or a C structure composed of other structures, enumerations
and primitive types, among others. The configuration instances are then XML instance files, ob-
ject diagrams, sets of Excel tables, sets of CSV tables, or C structures with constant, pre-assigned
values. All formats can represent the same information. In the following, we will focus on a
configuration representation in the form of a set of tables which are internally represented as CSV
tables. The tables are grouped according to their specification level (i.e., module level or partition
level). At module level, 13 configuration tables define module-global information like, for exam-
ple, the number of avionics partitions and the interface links and busses. At partition level, the
partition configuration data such as partition name, temporal and spatial allocation and communi-
cation ports are defined in 16 configuration tables for each partition. Consequently, a module with
one avionics partition is configured by 29 tables, for two partitions 45 tables are needed, and so on.
The number of rows of each table depends on the type of table. For example, global data at module
level (GLOBAL DATA) and temporal and spatial allocation for one partition (TEMPORAL ALLOCATION,
SPATIAL ALLOCATION) are each defined by a table with exactly one row. The number of rows for
the health monitoring configuration tables (HM SYSTEM, HM MODULE and HM PARTITION) depends on
the number of error sources (i.e., fixed number of rows). For the other tables, the number of rows
depends on the number of links, busses, messages and signals to be defined for the module and
the partitions. Figure 3.4 depicts how an IMA module configuration is composed of module-level
and partition-level configuration tables.
In the following sections, the formats (i.e., the parameters) of the different configuration tables
are described: Section 3.2.1 provides the column description for the module-level configuration
tables, and Sect. 3.2.2 defines the partition-level configuration tables. The format is compiled
according to the descriptions in [ARINC653P1 d4s2] with regard to the configuration tables used
for the IMA modules tested in the VICTORIA project. The format of the latter is confidential
and the described tables are an extract containing the obvious and most relevant configuration
parameters. Moreover, to limit the amount of implementation specific information, certain sets of
configuration parameters are abstracted by a single parameter – denoted by parameter names in
italics.
An IMA module configuration thus consists of a set of configuration tables which assign concrete
values to the configuration parameters. For abstracted parameters, no values are provided. All spe-
cific configuration values have to comply with the hardware characteristics of the IMA platform,
e.g., with the memory or the number and properties of the interfaces provided by the module. Such
technical data are provided by technical user guides and hardware mapping tables. In addition, the
module-level configuration data have to comply with the needs of the partitions which are defined
in the partitions’ configuration table. For example, for scheduling, the duration of the major time
frame (parameter MAF DURATION in table GLOBAL DATA) has to be a multiple of all partition periods
(for each partition: parameter PARTITION PERIOD in table TEMPORAL ALLOCATION).
72 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

IMA Module Configuration


1 1

1 1..PARTITION NB

Module-Level Configuration Tables Partition-Level Configuration Tables


1 1

1 1
GLOBAL DATA GLOBAL PARTITION DATA

ERROR NUM 1
HM SYSTEM TEMPORAL ALLOCATION

ERROR NUM 1
HM MODULE SPATIAL ALLOCATION

* AFDX OUTPUT VL ERROR NUM


HM PARTITION

* AFDX INPUT VL * AFDX OUTPUT MESSAGE

* A429 OUTPUT BUS * AFDX INPUT MESSAGE

* A429 INPUT BUS * A429 OUTPUT LABEL

* CAN OUTPUT BUS * A429 INPUT LABEL

* CAN INPUT BUS * CAN OUTPUT MESSAGE

* DISCRETE OUTPUT LINE * CAN INPUT MESSAGE

* DISCRETE INPUT LINE * DISCRETE OUTPUT SIGNAL

* ANALOGUE OUTPUT LINE * DISCRETE INPUT SIGNAL

* ANALOGUE INPUT LINE * ANALOGUE OUTPUT SIGNAL

* ANALOGUE INPUT SIGNAL

* OUTPUT DATA

* INPUT DATA

Figure 3.4: IMA module configuration consisting of several tables at module and partition level

Examples of IMA module configurations are included in Appendix C: Appendix C.1 provides
the module- and partition-level configuration tables for a module with two avionics partitions
(configuration tables for system partitions are not included). Appendix C.2 provides a set of
configuration tables which have been changed with respect to the ones in Appendix C.1 by adding
a pair of AFDX ports for each partition. Finally, Appendix C.3 provides the configuration tables
for a module with four avionics partitions.

3.2.1 Module-level Configuration Tables

At the module level, the configuration tables define the number of partitions, global scheduling
data (e.g., the duration of the major time frame), the different module-level memory areas, the
3.2. CONFIGURABILITY OF IMA PLATFORMS 73

health monitoring responsibilities and the respective module-level actions, and the interface busses
and lines used by the partitions.
The module-level configuration tables can be grouped into three categories: general module con-
figuration data (Sect. 3.2.1.1), health monitoring configuration data (Sect. 3.2.1.2), and I/O con-
figuration data (Sect. 3.2.1.3).

3.2.1.1 General Module Configuration Table

This table defines the general configuration parameters of the module. For each IMA module
configuration, the table contains exactly one row (see, for example, Table C.1).

GLOBAL DATA
PARTITION NB number of avionics partitions
SYS PARTITION NB number of system partitions
MAF DURATION scheduling data: duration of the major time frame, has to be a
multiple of all partition periods
CACHE CONFIG cache configuration data
RAM BEGIN start address of memory for the OS and drivers
RAM SIZE memory size for the OS and drivers
CFG AREA BEGIN start address of memory for the configuration data
CFG AREA SIZE memory size for the configuration data
MAC ADDRESS MAC addresses for sending and reception
MODULE LOCATION identifier for location within the aircraft architecture

3.2.1.2 Health Monitoring Configuration Tables

These tables define which error has to be handled at which level (table HM SYSTEM) and what the
recovery actions are to be taken if these errors shall be handled at module level (table HM MODULE).
For each possible error source, the tables contain one row (see, for example, Table C.1).

HM SYSTEM
ERROR SOURCE detected error (e.g., configuration error, divide by 0, overflow, ini-
tialization error, deadline missed, stack overflow, power interrupt,
I/O access error)
RECOVERY LEVEL defines the level at which the error is handled, possible levels:
module level and partition level

HM MODULE
ERROR SOURCE detected error
RECOVERY ACTION defines the action when considered as module-level error, possible
actions: reset, shutdown, ignore

3.2.1.3 I/O Configuration Tables

These tables define the AFDX virtual links, ARINC 429 and CAN busses, and the analog and dis-
crete lines. For each communication medium, input and output is distinguished. The configuration
data have to comply to the hardware interfaces provided by the module. For example, if the IMA
platform provides N discrete inputs it is only possible to configure up to N discrete input lines,
74 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

i.e., the table DISCRETE INPUT LINE can have up to N rows with configuration values. Examples
are provided in Table C.10 and Table C.11.

AFDX OUTPUT VL
VL NAME name of the virtual link (VL)
VL ID unique identifier for the VL
NETWORK selected network (one, several or all of the redundant AFDX net-
works)
PORT ID unique identifier for the AFDX port
PORT CHARAC type of the AFDX port (queuing or sampling)
PORT TRANS TYPE port transmission type (unicast or multicast)
VL DATA VL parameter such as bandwidth allocation gap (BAG), number
of sub VLs, buffer size used for the port in the modules RAM,
maximum payload, etc.
IP ADDR source (i.e., own) and destination IP address
UDP PORT identifier of source (i.e., own) and destination UDP port

AFDX INPUT VL
VL NAME name of the virtual link (VL)
VL ID unique identifier for the VL
NETWORK selected network (one, several, or all of the redundant AFDX net-
works)
PORT ID unique identifier for the AFDX port
PORT CHARAC type of the AFDX port (queuing or sampling)
VL DATA VL parameter such as buffer size used for the port in the modules
RAM, maximum payload, etc.
IP ADDR destination (i.e., own) IP address
UDP PORT identifier of destination (i.e., own) UDP port

A429 OUTPUT BUS / A429 INPUT BUS


BUS NAME name of the ARINC 429 bus
CONNECTOR cavity and pin location on the ARINC 600 connector

CAN OUTPUT BUS / CAN INPUT BUS


BUS NAME name of the CAN bus
CONNECTOR cavity and pin location on the ARINC 600 connector

DISCRETE OUTPUT LINE / DISCRETE INPUT LINE


LINE NAME name of the discrete line
CONNECTOR cavity and pin location on the ARINC 600 connector as well as its
role (e.g., set switch, read status, etc.)

ANALOG OUTPUT LINE / ANALOG INPUT LINE


LINE NAME name of the analog line
CONNECTOR cavity and location on the ARINC 600 connector as well as its
role (e.g., read voltage, read temperature, etc.)
3.2. CONFIGURABILITY OF IMA PLATFORMS 75

3.2.2 Partition-level Configuration Tables

At the partition level, the configuration tables define the general partition data (e.g., partition name
and identifier, the application to which the partition belongs to, etc.), the temporal and spatial
configuration data, the health monitoring actions at partition level, and the communication ports
and messages and signals used by the partition. Each partition is configured by its set of partition-
level tables and, therefore, the partition identifier is contained in each table.

The partition-level configuration tables can be grouped into three categories: general partition
configuration data including the scheduling and memory parameter of the partition (Sect. 3.2.2.1),
partition health monitoring configuration data (Sect. 3.2.2.2), and communication configuration
data (Sect. 3.2.2.3).

3.2.2.1 General Partition Configuration Tables

These tables define the general partition configuration parameters such as partition name and
identifier and configuration parameter for the main process (GLOBAL PARTITION DATA) as well as
the partition-relevant scheduling and memory configuration parameter (TEMPORAL ALLOCATION and
SPATIAL ALLOCATION). For each partition in a IMA module configuration, the tables contain ex-
actly one row (see, for example, Table C.3).

GLOBAL PARTITION DATA


PARTITION ID partition identifier (unique within the module)
PARTITION NAME partition name (unique within the module)
APPLICATION NAME name of the associated application (unique within the module but
another partition can belong to the same application
APPLICATION ID identifier of the associated application
CACHE CONFIG cache configuration data (to restrict the module cache configura-
tion)
MAIN STACK SIZE stack size of the main process
MAIN ADDR start address of the main process in the partition’s code, i.e., the
name of the main function
PROCESS STACK SIZE size of the memory area to be used for the stack of the other pro-
cesses (each process gets a dedicated memory area located within
this one); the process stack area is located in the data area of the
partition
MMU CONFIG configuration data for the MMU data relevant to the partition

TEMPORAL ALLOCATION
PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
PARTITION PERIOD scheduling period for the partition
SCHED WINDOW POS position of the scheduling window within the MAF (each position
can be assigned to one partition only within the module)
SCHED WINDOW OFFSET offset of the respective scheduling window from the beginning of
the MAF
SCHED WINDOW DURATION duration of the respective scheduling window
76 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

SPATIAL ALLOCATION
PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
CODE AREA BEGIN start address of the code area
CODE AREA SIZE memory size of the code area
DATA AREA BEGIN start address of the data area; data area contains process stacks,
administrative blocks for each port type, for the buffers, black-
boards, events, and semaphores, and for the global variables
DATA AREA SIZE memory size of the data area

3.2.2.2 Partition Health Monitoring Configuration Table

This table defines the recovery actions if an error is handled at the partition level. Additionally,
it is configured if the error is allowed to be handled by the error handler process (if created). For
each possible error source, the table contains one row (see, for example, Table C.3).

HM PARTITION
PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ERROR SOURCE detected error
RECOVERY ACTION action when considered as partition-level error and error handler
not allowed (see HANDLER RECOVERY) or not created or error oc-
curred within the handler, possible actions: partition idle, warm
start, cold start, ignore
HANDLER RECOVERY defines if the respective error can be handled at process level by
an error handler, possible values: yes or no

3.2.2.3 Communication Configuration Tables

These tables define the messages, labels and signals used by the partition as well as the inter-
partition communication ports. The communication ports are associated with a message, label,
signal, or other API port depending on the communication medium used for data transmission.
Each message, label, signal, and port is defined in a separate row of the respective configuration
table. Examples for AFDX messages and API ports using AFDX are provided in Table C.12 and
Table C.13.

AFDX OUTPUT MESSAGE


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED VL NAME name of the VL defined in the module configuration table
AFDX OUTPUT VL
ASSOCIATED AFDX PORT ID identifier of an AFDX port defined in the module configuration
table AFDX OUTPUT VL, has to be an AFDX port defined for the VL
with name ASSOCIATED VL NAME
TYPE DATA type information
3.2. CONFIGURABILITY OF IMA PLATFORMS 77

AFDX INPUT MESSAGE


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED VL NAME name of the VL defined in the module configuration table
AFDX INPUT VL
ASSOCIATED AFDX PORT ID identifier of an AFDX port defined in the module configuration
table AFDX OUTPUT VL, has to be an AFDX port defined for the VL
with name ASSOCIATED VL NAME
TYPE DATA type information

A429 OUTPUT LABEL


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED A429 BUS name of the A429 bus defined in the module configuration table
A429 OUTPUT BUS
A429 LABEL NAME name of the A429 label
A429 LABEL NUMBER number of the A429 label
SIGNAL LSB position of the LSB in the A429 word
SIGNAL MSB position of the MSB in the A429 word
TYPE DATA type information including minimum and maximum values, reso-
lution, etc.

A429 INPUT LABEL


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED A429 BUS name of the A429 bus defined in the module configuration table
A429 INPUT BUS
A429 LABEL NAME name of the A429 label
A429 LABEL NUMBER number of the A429 label
SIGNAL LSB position of the LSB in the A429 word
SIGNAL MSB position of the MSB in the A429 word
TYPE DATA type information including minimum and maximum values, reso-
lution, etc.

CAN OUTPUT MESSAGE


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED CAN BUS name of the CAN bus defined in the module configuration table
CAN OUTPUT BUS
CAN MSG NAME name for the CAN message
CAN MSG ID identifier for the CAN message
CAN MSG PAYLOAD payload of the message (in byte)
SIGNAL LSB position of the LSB in the CAN frame
SIGNAL MSB position of the MSB in the CAN frame
TYPE DATA type information
78 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

CAN INPUT MESSAGE


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED CAN BUS name of the CAN bus defined in the module configuration table
CAN INPUT BUS
CAN MSG NAME name for the CAN message
CAN MSG ID identifier for the CAN message
CAN MSG PAYLOAD payload of the message (in byte)
SIGNAL LSB position of the LSB in the CAN frame
SIGNAL MSB position of the MSB in the CAN frame
TYPE DATA type information

DISCRETE OUTPUT SIGNAL


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED LINE name of the discrete line defined in the module configuration table
DISCRETE OUTPUT LINE
SIGNAL NAME name of the signal
DEFAULT VALUE default value (GND, open, or 28V)

DISCRETE INPUT SIGNAL


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED LINE name of the discrete line defined in the module configuration table
DISCRETE INPUT LINE
SIGNAL NAME name of the signal
LOGIC interpretation logic of the value (positive or negative)

ANALOG OUTPUT SIGNAL


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED LINE name of the analog line defined in the module configuration table
ANALOG OUTPUT LINE
SIGNAL NAME name of the signal
TYPE DATA type information including minimum and maximum values, reso-
lution, value conversion parameters, etc.

ANALOG INPUT SIGNAL


PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
ASSOCIATED LINE name of the analog line defined in the module configuration table
ANALOG INPUT LINE
SIGNAL NAME name of the signal
TYPE DATA type information including minimum and maximum values, reso-
lution, value conversion parameters, etc.
3.2. CONFIGURABILITY OF IMA PLATFORMS 79

OUTPUT DATA
PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
PORT NAME name of the port
PORT CHARAC type of the port (queuing or sampling)
PORT MAX MSG SIZE maximum message size to be transmitted by the port
PORT MAX MSG NB for queuing ports the maximum number of queued messages,
empty for sampling ports
MEDIUM TYPE type of the communication medium (module-internal RAM,
module-external AFDX, A42, CAN, DISCRETE, or ANALOG)
ASSOCIATED PORT for RAM ports, it contains the receiving API port name
and its partition identifier; for the other communication me-
dia it defines the associated AFDX port identifier or name
of the label, message, or signal depending on the com-
munication medium used (name or identifier as defined
in AFDX OUTPUT VL, A429 OUTPUT LABEL, CAN OUTPUT MESSAGE,
DISCRETE OUTPUT SIGNAL, or ANALOG OUTPUT SIGNAL, respec-
tively)
TYPE DATA type information for the payload like message type, FDS configu-
ration data, etc.

INPUT DATA
PARTITION ID partition identifier (as defined in the configuration table
GLOBAL PARTITION DATA)
PORT NAME name of the port
PORT CHARAC type of the port (queuing or sampling)
PORT MAX MSG SIZE maximum message size to be transmitted by the port
PORT MAX MSG NB for queuing ports the maximum number of queued messages,
empty for sampling ports
MEDIUM TYPE type of the communication medium (module-internal RAM,
module-external AFDX, A42, CAN, DISCRETE, or ANALOG)
ASSOCIATED PORT for RAM ports empty; for the other communication me-
dia, it defines the associated AFDX port identifier or
name of the label, message, or signal depending on the
communication medium used (name or identifier as de-
fined in AFDX INPUT VL, A429 INPUT LABEL, CAN INPUT MESSAGE,
DISCRETE INPUT SIGNAL, or ANALOG INPUT SIGNAL, respectively)
TYPE DATA type information for the payload like message type, FDS configu-
ration data, etc.

3.2.3 Configuration Responsibilities and Change Management


The module- and partition-level configuration tables contained in an IMA module configuration
are assembled by a single authority – the system integrator. However, they include configuration
information and requirements of the partitions which are provided by the application supplier.
This information cannot be provided in the format needed for the partition-level configuration
tables described above because

• the application supplier knows the application’s communication partners but has no explicit
information regarding the location (module and partition number) of the respective partitions
(i.e., the supplier’s own ones as well as those of the communication partner),
80 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

• the application supplier defines how many different AFDX VLs, ARINC 429 or CAN
busses, or analog or discrete lines are required (to comply with the redundancy concept
and safety requirements) but does not explicitly define on which links, busses or lines these
messages, labels and signals are transmitted,

• the application supplier does not know on which module(s) the partitions of its application
are running,

• the application supplier knows the memory requirements for code and data areas but does
not require to know their exact location in the module’s memory, and

• the application supplier knows the scheduling requirements of its partition(s) but is not
aware of the sequence of partition activations within a module.

Nevertheless, other configuration data is defined by the application suppliers and has to be included
by the system supplier in the partition-level configuration tables. For example, the application
supplier defines the names and characteristics of its input and output communication ports.

Contract Model. To overcome the problem of different competences and responsibilities, a con-
tract model between the system integrator and the application suppliers is suggested by Verocel
(see [Ver05]) for consideration in future versions of ARINC 653. The aim of this contract model
is to allow the application suppliers to define their requirements separately from the respective
partition-level configuration tables and from the configuration requirements of the other applica-
tions, and to ensure that the system integrator provides adequate module configurations. The con-
tracts are of additional value when considering configuration changes which are likely to occur
during early development phases and when applications are enhanced with additional functional-
ity. Then, the contracts ensure that (a) the system supplier changes the module configuration as
requested, and (b) that changes requested by other applications hosted on the same module do not
conflict with the requirements of the application.

Configuration Management. In general, the significance of configuration management is of-


ten underestimated which becomes apparent when analyzing the respective processes and tools
and the consideration of configuration management in the various standards and guidelines. For
general safety-critical systems, this problem is discussed in detail by [Sto04] stating that config-
uration data is often assumed to be static and unchanging without considering that configuration
changes require the same revalidation and recertification activities as changes to the software or
hardware. When verifying and certifying IMA modules and systems using IMA, the use of differ-
ent configurations is considered adequately as described in Chap. 5. Nevertheless, the approach
described there expects to use consistent configurations and adequate tool support for checking the
consistency of IMA module configurations is rare. Configuration change management thus often
remains a manual activity.

References
An XML configuration schema as well as some simple examples are included in
[ARINC653P1 d4s2]. Configuration management for IMA modules and safety-critical systems
in general is addressed by [Ver05] and [Sto04].
3.3. DEVELOPING APPLICATION SOFTWARE FOR IMA PLATFORMS 81

3.3 Developing Application Software for IMA Platforms

When developing application software to be running on an IMA module, the application supplier
has to consider the characteristics of the operating system and the hardware platform as well as
the configuration possibilities and limitations. Of course, for a specific application, the application
supplier also has to regard the application-specific requirements with respect to system behavior,
system and software design, and other detailed information (e.g., on algorithms), but such consid-
erations are independent of the target platform and are thus not considered in this section.
With respect to configuration, the application supplier has to consider mostly the partition-level
configuration data provided by the system integrator based on the application supplier’s initial
requirements. This means for the initial configuration that each application supplier specifies its
minimum requirements based on the application design and the system integrator then generates
the configurations for all IMA modules of the domain and for each partition. However, during
the coding phase and when enhancing the application with additional functionality, it has to be
checked if the configuration is still sufficient or if configuration changes are necessary. Config-
uration changes of one partition may have a major impact on the overall configuration and thus
are usually considered as the last resort when it is not possible to cope with the restrictions of the
configuration.
However, considering the restrictions imposed by a particular configuration is not only interesting
for application development but also for testing the IMA module’s operating system. For example,
when testing the memory allocation in the process stack area of a partition (defined by parameter
PROCESS STACK SIZE), it has to be calculated how many processes N can be created with a given
process stack size according to the OS specification in order to verify that N processes can be cre-
ated and used, but N + 1 cannot. The same calculations have to be performed when changes in the
application implementation require more processes: Then, it has to be checked if the configuration
still allows to create all processes or if more memory has to be reserved for the application. The
latter requires to change the partition-level configuration and, thus, has to be co-ordinated with the
system integrator.
Hence, the considerations for application software development and finding test objectives are
related and include (but are not limited to):

Partitions. Each application can consist of one or more partitions which are either located on
the same module or on different modules depending on their configuration requirements,
safety requirements, and the system architecture defined by the system integrator. Similar
to communication with other partitions, the partitions belonging to the same application
have to use the common API services for intra-application communication.

Inter-Partition Resource Sharing. The resources of an IMA module are shared by several par-
titions which means that CPU, memory space, and HW interfaces are not uniquely assigned
to one application. In particular, it has to be considered that there are predetermined periods
when other partitions are scheduled which can also mean that the currently running process
is interrupted at the end of its partition’s scheduling window (which may result in missed
deadlines). Furthermore, memory area is limited and therefore pre-allocated for particular
purposes (e.g., to store the code, the global variables, partition-related OS control blocks, or
the process stacks of a specific partition). In addition, further memory allocation at runtime
is not supported to ensure a predictable execution time.

Intra-Partition Resource Sharing. The tasks of a partition can be accomplished by several pro-
cesses which share the common resources allocated to the partition, i.e., all communication
ports, the partition data, etc. However, it has to be considered that (a) writing into a sam-
pling port or blackboard overwrites the previous message (potentially without having been
82 CHAPTER 3. INTRODUCTION TO IMA PLATFORMS

read before), and (b) reading from a queuing port or buffer is destructive. Moreover, it has
to be considered that the sender and the receiver of a message are partitions and not specific
processes running in these partitions, i.e., unless encoded in the message itself, the receiver
has no information about the sender process and can thus not distinguish messages from
different sender processes.

Pre-allocated Memory Areas. The memory areas to be used by a partition are defined in the
configuration. The executable code of the partition has to fit in its code area (configured by
the parameters CODE AREA BEGIN and CODE AREA SIZE). The data area (configured by the pa-
rameters DATA AREA BEGIN and DATA AREA SIZE) is used for the the global variables defined
in the source code, the stacks of the processes, and the control blocks required by the OS
for managing the communication objects (e.g., ports, buffers). For the process stacks, the
memory is already pre-allocated in the configuration by parameter PROCESS STACK SIZE. For
communication objects, the required memory is allocated during object creation (e.g., port
creation, buffer creation) and the different types of objects compete for it. If – by mistake
– not enough data area is configured, the sequence of creation determines which objects
cannot be created any more.

Portability. Application software shall be HW-independent and portable meaning (a) that the par-
tition uses the OS services to access the HW interfaces and to affect the process scheduling,
(b) that the application software is written independently of its location and the location
of its communication partners, and (c) that the application software makes no assumptions
about the implementation of the OS other than given in the respective OS specification (e.g.,
ARINC 653 specification).

Inter-Partition Communication Objects. For creating sampling and queuing ports, the respec-
tive parameters (e.g., port name and maximum message size) are defined in the configura-
tion; non-configured ports cannot be created. If additional ports or different port characteris-
tics are needed, the required configuration changes have to be co-ordinated with the system
integrator and the respective communication partners.

Communication Objects. All inter-partition and intra-partition communication objects can be


used directly after their creation in any operating mode (i.e., during COLD START, WARM START,
and NORMAL). For example, a destination queuing port can be used for receiving messages
directly after its creation in operating mode COLD START (provided that the communication
partner has already sent a message).

Operating System Limitations. Regardless of the configuration restrictions, the operating sys-
tem defines the system limit number of processes, ports, etc. For example, although enough
memory is available to manage 300 blackboards, the operating system’s limit is 256.

Summarizing, for developing an application, the configuration requirements have to be agreed


upon with the system integrator which then compiles adequate configurations for the modules
hosting the application’s partitions. However, the configuration requirements often change be-
cause (a) the behavior has to be implemented in a different way than planned beforehand which,
for example, may require more processes and intra-partition communication objects, (b) fault cor-
rection requires different algorithms, or (c) the implementation of new features requires additional
variables, processes, or communication objects. In these cases, it has to be checked if the appli-
cation’s currently configured resources are still sufficient or if the implementation changes also
require configuration changes.
Test applications have to consider the same configuration possibilities and limitations. In contrast
to real applications, the test applications check the operating system’s behavior and usage of the
configuration. Therefore, in some test cases, the test applications fully exploit the configured
3.3. DEVELOPING APPLICATION SOFTWARE FOR IMA PLATFORMS 83

resources in order to verify that, for example, the data area is shared as specified and can be
allocated completely. Thus, it is guaranteed that real applications can be safely changed as long as
this does not require more resources.

References
The characteristics of the operating system to be used for IMA platforms are defined in the ARINC
653 API specification [ARINC653P1 d4s2] that also directly addresses some of the above consid-
erations, e.g., partitions and inter-partition resource sharing (p. 2, 3, 108), intra-partition resource
sharing (p. 11, 27), memory allocation (p. 13, 26), portability (p. 6), operating system limitations
(p. 125, 148 for Ada, p. 170 for C). The configuration details are not discussed there, but follow
the configuration description in the previous section.
84
Chapter 4

System Architectures using Integrated


Modular Avionics

The concept of integrated modular avionics is to use IMA platforms as the main modular building
blocks to create complex structures which shall, on the one hand, provide the execution platform
for the aircraft functions and, on the other hand, support fault tolerance as required by the sever-
ity levels of the respective systems. Thereby, the specific characteristics of IMA platforms (as
described in the previous chapter) affect the possible and required characteristics of system ar-
chitectures using integrated modular avionics. Such system architectures usually require specific
system engineering processes for development as well as verification and validation. While the
latter is discussed in detail in the following chapter, this chapter aims at analyzing and discussing
the architectural features and peculiarities required for understanding the changing system engi-
neering processes for IMA architectures.
The system architecture of an aircraft can be considered at two levels: aircraft level and system
level. While the aircraft-level architecture comprises the components of all systems and focuses on
their interconnection and their physical location in the aircraft, the architecture at the system level
describes in more detail the setup of the systems, i.e., their controllers and peripheral equipment.
In the following, Sect. 4.1 analyzes the general characteristics of an aircraft-level architecture and
Sect. 4.2 discusses the features of typical system-level architectures.

4.1 IMA Architecture at the Aircraft Level

An architecture specification at the aircraft level comprises the platforms for all avionics func-
tions – from flight control to passenger entertainment – and describes their interconnection as
well as their physical location in the aircraft. As mentioned above, a typical IMA architecture
stands out by being composed of different types of a shared IMA module and several types of pe-
ripheral equipment. Where necessary, the architecture may also comprise special-to-purpose and
COTS platforms as controllers. The controller platforms are extensively connected by fast digi-
tal data busses for inter-system communication and by analog or digital lines for communication
with the respective peripheral equipment – either directly with the sensors and actuators or via
intermediate so-called remote data concentrators. Within an IMA architecture, a typical choice
for a controller-to-controller data bus is AFDX, whereas for controller-equipment communication
others are preferred, e.g., CAN, ARINC 429, analog signals, and discrete signals.
As stated in [DP04] (p. 4), the physical architecture of an aircraft like the Airbus A380 contains
the interconnected platforms and peripherals for about 100 aircraft functions. Although enormous
reductions have been achieved by the use of shared platforms like IMA modules and digital data
buses such as AFDX and CAN, the physical architecture still comprises very many network nodes

85
86 CHAPTER 4. SYSTEM ARCHITECTURES USING IMA

and their connections and, therefore, it is advisable to further structure the aircraft-level architec-
ture, e.g., into different domains. Usually, two complementary types of domains are distinguished:
(1) so-called functional domains which provide a functional grouping and (2) so-called aircraft do-
mains which separate the aircraft networks according to the criticality of the comprised systems.
However, the enormous number of network nodes also results from implementing redundancy
concepts that are necessary to achieve the required level of fault tolerance for each aircraft func-
tion. This means that identifying redundant platforms also supports the structuring approach. The
following paragraphs at first discuss the architectural characteristics of the two domain types, then
discuss redundancy concepts at aircraft level, and finally briefly address structuring according to
the physical location of the components. The section concludes by analyzing a sample aircraft
architecture in Sect. 4.1.1.

Functional Domains. To provide a structure in the overall aircraft architecture, the aircraft func-
tions are functionally grouped into so-called domains. These typically comprise the flight control
domain, engine domain, cockpit domain, cabin domain, utilities domain, energy domain, OIS do-
main and PCES domain (see Sect. 1.1 for a short characterization of each domain). This approach
of distributing the systems across different domains also reflects the diverse requirements with re-
spect to safety and security which have to be considered when choosing the system architectures
and the redundancy concepts, but also when choosing the tools and methods during the develop-
ment process. For example, the systems in the flight control and the engine domain are obviously
most safety critical and therefore require redundant and diverse controllers. On the other hand, the
systems in the PCES domain are provided for comfort and entertainment and are not required for
safe flying – thus, the demands for redundancy are less stringent. Even less critical with respect
to safety are the passenger-owned devices which nowadays can access the on-board information
systems or the Internet. However, with respect to security, functional grouping is not sufficient to
avoid possible undesired intrusions, e.g., from passenger-owned devices to flight control. There-
fore, the functional grouping has to be complemented by physically separating the systems of
different criticality by assigning them to different aircraft domains.

Aircraft Domains. To ensure the appropriate level of safety and security to each system in an
IMA architecture, it is recommended to assign the systems to different networks which are phys-
ically separated by appropriate means but still allow exchange of well-defined data. As described
in Sect. 1.6, it is common to divide the aircraft computing network into four sub-networks (also
called aircraft domains). Thus, aircraft control systems (belonging to sub-network 1) are sepa-
rated from airline information services (sub-network 2), passenger information and entertainment
services (sub-network 3), and passenger-owned devices (sub-network 4).
However, the separation into these four aircraft domains is somehow driven by theoretical con-
siderations and, in practice, the architectures often consider only two or three separate networks:
All systems which do not belong to the aircraft control network are considered to be open world
and are separated from the networks in the aircraft control domain by a secured communication
interface (SCI). Depending on which systems are considered to be in the open world, passenger-
owned devices may be further separated. In the following section’s analysis of a sample aircraft
architecture, this different aircraft domain structure can be observed: Systems belonging to the
OIS domain which provide or collect administrative data (and thus should be assigned to the sep-
arated airline information services domain) are connected directly to the aircraft control network.
However, this different allocation of systems to separated networks does not necessarily result in
a lower level of security and safety since it can be compensated by appropriate verification and
validation means.

Redundancy Concepts at the Aircraft Level. Wherever required, appropriate redundancy con-
cepts are implemented ranging from duplicated software on duplicated platforms (e.g., for the
4.1. IMA ARCHITECTURE AT THE AIRCRAFT LEVEL 87

cabin intercommunication data system) to dissimilar software running on platforms with different
hardware architecture (e.g., for the flight controller). Additionally, redundancy is provided for
the inter-controller network (usually by duplicated wiring) and the data busses and signals to the
peripheral equipment (usually by different busses to sensors or actuators at the same location).
These forms of redundancy also require a redundant power supply with important controllers con-
nected to both supplies. Identifying redundant controllers is one additional mean for structuring
the aircraft architecture.

Physical Architecture. One main characteristic of integrated modular avionics is the use of
shared platforms where several system controllers share the computing, memory, and interface
resources of one IMA module. Thus, each functional domain has a set of IMA modules which
host the controlling and monitoring functions of the systems and which are connected to the AFDX
network for communication with systems hosted by other modules (either located in the same or
in a different functional domain). For redundancy, the modules as well as the communication
network are duplicated (or triplicated) and placed at different locations in the aircraft to support
the ability to manage system loss caused by smoke or fire without losing functions whose loss
would be catastrophic.

4.1.1 Analysis of a Sample Aircraft Architecture

There are only very few IMA aircraft architectures published which can be used for more detailed
analysis. Examples of a potential A380 architecture are shown, for example, in [DP04] (p. 4) and
quite similarly also in [ZB05]. In this thesis, we will further analyze an aircraft architecture shown
in Fig. 4.1 which is based on these examples. The figure depicts the controller platforms of the
systems (white boxes) and their interconnections (red and blue lines). The figure does not contain
any peripheral equipment like actuators or sensors, but for a few systems remote data concentrators
are also contained. All names of the systems and system components are abbreviated and the long
forms of the acronyms are given in Appendix G. The following paragraphs analyze the depicted
aircraft architecture with respect to redundancy and grouping as described above.

Network Redundancy. The network used in the sample aircraft architecture is a redundant
switched network – probably an AFDX network. Figure 4.2 focuses on this detail by emphasizing
only the fully redundant wiring (blue and red lines) and AFDX switches (blue and red nodes). The
open world is connected to the SCI using a different networking technology – probably Ethernet
– without further redundancy (single black line).

Assignment to Aircraft Domains. When assigning the systems to their probable aircraft do-
mains, it becomes obvious that almost all explicitly mentioned systems belong to the aircraft
control domain and only a few belong to the airline information services domain and provide
administrative information or passenger information and entertainment support. All systems be-
longing to the open world may be assigned to one of the latter ones depending on their task. This
assignment to the aircraft domains is emphasized in Fig. 4.3 which also shows that the redundant
AFDX network is primarily used for controller-to-controller communication within the aircraft
control domain. The passenger-owned devices aircraft domain is not shown because, at most, the
respective gateway platform is part of the aircraft architecture.

Assignment to Functional Domains and Redundancy of Systems. The sample aircraft archi-
tecture in Fig. 4.1 already sketches a possible functional separation of the systems into the eight
different functional domains distinguished in this thesis. Unlike the figure in [DP04] (p. 4) – where
88 CHAPTER 4. SYSTEM ARCHITECTURES USING IMA

Fligh Control Domain


FCSC1 FCGC1 FCGC2 FCSC2
COM MON COM MON COM MON COM MON SFCC2
SFCC1
COM MON COM MON
FCGC3 FCSC3
COM MON COM MON
Cockpit Domain

IOM IOM

ADIRU1 FM1 FM2 ADIRU2


ADIRU3 FM3
EEC3
EEC1

Engine Domain
L1 L2 C1 R2 R1
Engine Domain

EHM3
EHM1
ACR1 ATC2
ATC1 L3 C2 R3 EEC4
EEC2
EHM4
EHM2

FW1 ACR2 (opt)


FCDC1
FW2
FCDC2
Open World

Open World
AESU1
AESU2
IOM
ELM ACMF ELM OIS Domain
CBM FDIF CBM
SB24 HSM HSM SB24
SCI SCI
AIC2 AIC2
Utilities Domain Fuel Fuel Utilities Domain
Energy Domain LG TP&BS
LG TP&BS COM MON COM MON

COM MON COM MON


ECB ext lights ctrl

PCES Domain IRDC


IRDC
CIDS CIDS IPCU
VSC IPCU
Cabin Domain PWCU
PESC

SPDB SPDB

Ventilation & ACF


pressurization Ventilation &
ACF
pressurization

Figure 4.1: Example of a possible A380 system architecture at the aircraft level

only four different groups are shown –, Figures 4.1 and 4.4 offer a more fine-grained subdivision
that splits the utilities group in [DP04] (p. 4) into systems belonging to the OIS domain, the energy
domain, the PCES domain, the cabin domain, and the utilities domain.
Further analysis of Fig. 4.1 shows that (a) the engine controllers are provided in quadruplicate to
assign one engine controller to each engine (emphasized in Fig. 4.4 as four green engine domain
boxes), (b) the systems in the flight control domain and the cockpit domain are mostly provided
in triplicate (depicted as three rose and three pink areas), and (c) the others are usually duplicated
(depicted as two boxes per domain).
In addition to this (hardware) redundancy, Figures 4.1 and 4.4 also point out the possible physi-
cal location of the platforms in the left-hand and right-hand side of an airplane. This is depicted
by the vertical symmetry axis. This presentation in the figures is motivated by knowing that the
redundant platforms are usually not located in the same area to protect them from disturbances
which occur only in one part of the aircraft (e.g., fire in one of the avionics compartments).

Assignment to Platforms. The architecture provided in Fig. 4.1 does not consider assignment of
systems to platforms. In particular, it is not shown which systems share a common IMA module.
This is depicted, for example, in [AV04a] for the cabin domain systems air conditioning, fire and
smoke detection system, doors and slides management system, and cabin pressure system. For
the utilities domain, [AV04f] shows that the controlling and monitoring components of the fuel
4.1. IMA ARCHITECTURE AT THE AIRCRAFT LEVEL 89

Open World

Open World
SCI SCI

Figure 4.2: Redundant switched network for interconnection of the platforms (based on Fig. 4.1)

system, the landing gear system, the braking system, and the steering system share two IMA
modules.

References
Brief design guidance for an IMA architecture at the aircraft level is given, among others, in
[AC20-145], p. 21. Sample IMA aircraft architectures are shown in [DP04], p. 4 and [ZB05].
Less detailed architectures are also shown in [Rag04], p. 7 and [Tha04d]. Examples of aircraft
architectures focusing on a single functional domain are also depicted in [AV04a] (cabin domain),
[AV04c] (cockpit domain), [AV04d] (energy domain), [AV04e] (OIS domain), [AV04b] (PCES
domain), and [AV04f] (utilities domain).
The different components contained in an aircraft architecture haven been described, compared
and categorized in the beginning of this thesis: different platform types in Sect. 1.5 and different
aircraft networking technologies in Sect. 1.6. The concepts of hardware, software and information
redundancy have been described in Sect. 1.4.
90 CHAPTER 4. SYSTEM ARCHITECTURES USING IMA

Passenger Information and


Entertainment Services Domain

Airline Information
Services Domain

Aircraft Control Domain

Open World SCI SCI Open World

Figure 4.3: Grouping into aircraft domains (based on Fig. 4.1)


4.1. IMA ARCHITECTURE AT THE AIRCRAFT LEVEL 91

Flight Control Domain Flight Control Domain

Fligh Control Domain

Cockpit Domain Cockpit Domain

Engine Domain Engine Domain


Cockpit Domain

Engine Domain Engine Domain

OIS Domain OIS Domain


Open World

Open World
SCI SCI
Energy Domain Energy Domain
Utilities Domain Utilities Domain

PCES Domain PCES Domain

Cabin Domain Cabin Domain

Figure 4.4: System redundancy and grouping into functional domains (based on Fig. 4.1)
92 CHAPTER 4. SYSTEM ARCHITECTURES USING IMA

4.2 IMA Architecture on System Level


As described above, an IMA architecture comprises several interconnected platforms which are
used by the system functions or applications for computing and system-to-system communication.
The platforms are also connected to several peripheral equipment because, for these calculations,
most systems also require several inputs from directly connected sensors and also generate outputs
for directly connected actuators. While the previous section has focused on the aircraft-level IMA
architecture and discussed the characteristics of the complete network of platforms, this section
briefly analyzes system-level IMA architectures and addresses their redundancy concepts.
Each system is usually composed of a controller part which gets inputs from sensors or other
systems and provides outputs to actuators or other systems, i.e., the system is connected at the
aircraft-level to other systems, but also sets up a network of its own at the system level for com-
munication with its peripheral equipment. For this controller-to / from-peripheral communication
typically other communication links are used than for inter-system communication (as already dis-
cussed in Sect. 1.6). The sensors and actuators can be connected to the computing platform either
directly – typically using digital or analog signals – or via so-called smart components or remote
data concentrators which convey the inputs and outputs of the connected sensors or actuators and
communicate with the platform using CAN or ARINC 429. Nowadays, the latter solution is usu-
ally preferred if the sensors and actuators of the system are physically distributed over large areas
of the aircraft because this allows significant reduction of wiring weight and space.
A typical architecture at the system level is depicted in [Spi01] (p. 33-9) addressing the fuel gaug-
ing system which is similarly also shown in [AV04f] and [MS03] (p. 302–308). The main charac-
teristic of fuel gauging systems is that the main controller is connected via ARINC 429 (or ARINC
629) to so-called fuel remote data concentrators (FRDCs) which are located close to the tanks and
which are connected to the sensors via analog or discrete signals. The task of the FRDCs is to
collect and combine the information from the sensors (e.g., the fuel temperature and density as
well as many other variables) and transmit them as data messages.
The architectures of other systems like the doors and slides management system are similar but
use CAN for connecting to the smart components.
The following paragraphs will further discuss typical redundancy concepts implemented for
system-level IMA architectures.

Redundancy Concepts at the System Level. The redundancy concepts at system level depend
on the considered system, i.e., highly safety-critical systems (e.g., the flight control system) im-
plement more elaborated concepts. In the following, we well further analyze the elaborated redun-
dancy concept of the flight control system.
Command and Monitor Elements. As shown in Fig. 4.1, highly-safety critical systems like the
flight control system, the slats and flaps control system, the landing gear system, and the fuel
system comprise command and monitor elements (white boxes labeled COM and MON, respec-
tively). Such a configuration increases the redundancy and allows cross-checking and integrity
checking. Usually, diversely developed software is used for the two elements. The utilities do-
main (aircraft-level) IMA architecture depicted in [AV04f] shows that the command and monitor
elements of the fuel system, the braking system, and the steering system are assigned to different
IMA modules.
Primary and Secondary Controllers. Another means for redundancy of highly-safety critical
systems is to provide primary and secondary computers. The flight control system has primary
flight control and guidance computer (FCGC) and the flight control secondary computer (FCSC)
which is a hot standby for the primary one. Both flight control computers are depicted in Fig. 4.1.
As described in [MS03] (p. 260), the concept is usually accompanied by dissimilar hardware and
software to be used for primary and secondary computers.
4.2. IMA ARCHITECTURE ON SYSTEM LEVEL 93

Redundant Controllers. In addition to the other redundancy concepts, the primary and secondary
controllers are each triplicated as it has also been depicted in Fig. 4.4. In less safety-critical
systems, the controllers are usually only duplicated.
Mechanical Reversion. The last means for redundancy of important computers is a mechanical
reversion, e.g., for the flight control system computers the reversionary flight control allows to
fly and land the aircraft manually. However, new aircrafts like the A380 use fly by wire without
the mechanical backup and compensate it by means of a direct electrical link and a considerable
degree of dissimilar redundancy ([MS03], p. 260–261, 283–286).

Network Redundancy. The redundancy concept applied for the intra-system network depends
on the criticality of the system and the type of communication link. For example, for most links
between the system’s main controllers and the local controllers or sensors/actuators located some-
where in the aircraft, duplication of the wires is not an option since this would double the weight
and volume of wiring. Otherwise, most systems have several sensors/actuators at one location
to protect the system against hardware failures of these components. Thus, redundant wiring is
already provided and the redundancy characteristics can be improved by connecting these redun-
dant wires to different power supplies. For example, for the smoke detection function (SDF), there
are several smoke detectors located in each compartment which are each connected to one of the
redundant SDF controllers via different CAN busses (which are in turn connected to normal power
or essential power).

References
System-level architectures – especially for highly-safety critical systems like the flight control
system – are addressed in several books (e.g., [MS03], [Spi01]). For example, [MS03] describes
the architecture of the flight control system for different architecture models and also addresses
their various redundancy concepts. The (aircraft-level) IMA architecture of the utilities domain in
[AV04f] also provides information about the implemented redundancy concept.
94
Chapter 5

Testing of Systems based on Integrated


Modular Avionics

In the beginning of this thesis – particularly in Sect. 1.1 and Sect. 1.7 – the general development
process for avionics systems has been described and differences with respect to the chosen ar-
chitecture or platform concept discussed. For systems based on integrated modular avionics, the
main characteristic is that different systems can be hosted on a standardized IMA platform that is
developed independently from the system’s application software to be running on the IMA module
(see Chap. 3). This means that if one type of IMA module is used for all applications, it is only
developed once. This separation of application development and associated platform development
is also depicted in Fig. 5.1 on the left hand side of the V. However, the figure focuses on the fur-
ther consequences for the right hand side of the V – the system test approach for avionics systems
using shared platforms like IMA modules. As pictured by the separate development and V&V
process for the IMA platform, a shared resource has to be tested only once and can then be used
by the applications.

Aircraft
Flight Tests
D1 D2 Ground Tests

System Integration Tests


S11 S12 S21 S22
Multi-System Tests

System Tests
         

         

                                             
 

 

 

                  

    

         

                                 
                 
E 111

E 121

E 211

E 221

    
IMA

         
             
                                 
 





     
                 

    

         
                                 

                 

    

             

 

 

 

           

          
plat

    

          
          

    


 


 




 




 




































Platform Tests
form

    

          
          

    

Application Tests