Challenges and Ways Forward for Avionics
Platforms and their Development in 2019
Bjoern Annighoefer Martin Halle
University of Stuttgart Hamburg University of Technology
Stuttgart, Germany Hamburg, Germany
bjoern.annighoefer@ils.uni-stuttgart.de martin.halle@tuhh.de
Christopher Watkins Steven H. VanderLeest
Gulfstream Aerospace Corporation squishLogic LLC
Savannah, GA, USA Grand Rapids, MI, USA
chris.watkins@gulfstream.com steve@squishlogic.com
Abstract—Today’s air vehicles depend on digital technology.
It accounts for more than 30% of their development costs. The
number of functions, the lines of code, the degree of autonomy,
and the number of vehicles rise. This is why there is a need
for cutting-edge technology and development methods. There is
a gap between academia’s methods and industrial applications
due to multi-disciplinary challenges. We summarize the state-
of-the-art in avionics, namely avionics platforms, requirements
engineering, model-based development, automated verification,
emerging technologies, and emerging demands. Experts review
the most demanding challenges, research gaps, and promising
solutions. They provide recommendations for the enhancement
of the cooperation between industry and academia and suggest
necessary research topics. This article is an introduction for those
who are new to avionics. It is an up-to-date summary, for insiders
looking for most promising solutions to their current problems;
and it is a guide for those advancing avionics research.
Index Terms—avionics platforms, requirements engineering,
model-based development, automated verification, multi-core
I. I NTRODUCTION
The term Avionics was coined in the 1960s. Today, avionics
accounts for over 30% of the aircraft development costs [1].
Software (SW) and electronics provide a main unique selling
point between aircraft and their airframers. There is a gap
between required cost and effort vs. acceptable ones and this
gap enlarges. New programs, small electric aircraft, air taxis,
drones, and autonomous vehicles are under development. The
cost per vehicle must be low. Moreover, the targeted degree
of autonomy is high. The situation demands for cutting-edge
methods of systems and SW engineering, i.e. formal methods,
model-based development, and development automation. For
instance, (1) the costs for the development of a digital fly-
by-wire system are still almost the same as for the first one.
(2) In the future, only multi-core processors will be available,
but certification remains quite challenging. (3) Autonomous
vehicles demand functions of a complexity that can hardly be
certified with the current methods. New and more efficient
methods are under research or already available. However,
discrepancies exist between what is needed in industry and
what is developed in academia.
978-1-7281-0649-6/19/$31.00 ©2019 IEEE
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
Andreas Schweiger, Marina Reich
Airbus Defence and Space GmbH
Manching, Germany
{andreas.schweiger,marina.reich}@airbus.com
Stefan Harwarth, Patrick Deiber
Wind River GmbH
Ismaning, Germany
{patrick.deiber,stefan.harwarth}@windriver.com
The number of avionics research summaries is limited.
Bieber et al. stated the integration of Commercial-off-the-
shelf (COTS) and multi-core processors into avionics as being
most important and proposed a predictive execution model [2].
Goodloe et al. indicated significant challenges in safety and
security in autonomy [3]. They proposed formal methods
and cyber-physical system models as ways forward. Gaska
et al. observed major challenges in the rising complexity
and development effort of avionics platforms [4]. They saw
a solution in open architectures and an economic dual-use
between avionics, the automotive domain, and Internet-of-
things (IoT). Our contribution is to update the picture as
of 2019, necessarily broadening the scope since there are
major multi-disciplinary challenges. This is also a result of the
AvioSE’19 workshop [5]. We target academia by quantifying
the current needs of the industry. We target industry by
summarizing innovative approaches and methods of academia.
Topics dealt with are:
• Avionics platforms, i.e. Integrated Modular Avionics,
safety-critical COTS, middleware, and self-organization
• Requirements engineering, i.e. Natural Language Pro-
cessing (NLP), Controlled Natural Language (CNL), and
formal specification
• Model-based development, i.e. general purpose or
domain-specific modeling languages, model transforma-
tion, code/document generation, and early validation
• Automated verification, i.e. virtual verification, theorem
proving, and model checking
• Emerging technologies, i.e. multi-core CPU, Time Sen-
sitive Networks (TSN), optical/power-line/data-centric
communication, virtualization, and containers
• Emerging demands, i.e. security, artificial intelligence,
and pilot-reduced/less cockpit
For each topic experts review the current state-of-the-art
and most important gaps are given in Sections II to VII. The
results are condensed in Sec. VIII to higher order research
recommendations and summarized in Sec. IX.
 II. AVIONICS P LATFORMS
Avionics platforms are state-of-the-art, composed of stan-
dardized computers, SW and bus systems. One party provides
the platform, others provide the SW, e.g. system functions.
Platforms strive to reduce Size, Weight, and Power, as well as
Cost (SWaP-C). However, platforms also exhibit challenges in
integration, certification, performance, and safety.
A. Integrated Modular Avionics
Integrated Modular Avionics (IMA) are avionics platforms
that share computing, Input/Output (IO) interfaces, and net-
work between several aircraft functions. Its benefits lead to
virtually every airframer leveraging IMA [4] and achieving
SWaP-C reductions. Moreover, IMA is the focus of important
avionics standards such as DO-297 incremental certification;
ARINC 653 operating system API; and ARINC 664 rate-
constrained Ethernet-based bus. Space and time partitioning
enabled co-hosting mixed-criticality functions, where certifi-
cation artifacts can be reused hosting an unmodified software
module. However, applications remain incompatible between
IMA systems. Detailed APIs, usage-domain rules, and con-
figuration parameters differ. Platform compatibility standards
would ease reuse and integration. Moreover, when a system is
architecturally mapped onto IMA, the inter-system dependen-
cies are not obvious, e.g. obscured by the network ”cloud”.
Developers struggle with questions like ”Whom do I depend
on?”, and ”What are the system boundaries?” since their
function is spread across many distributed components [6].
These dependencies are obscured in configuration data spread
across thousands of files. Graphical system modeling tools are
needed to help system integrators perform integration, and
help system owners understand the integration. In addition,
machine-readable models could make the platform aware of
expected data-flows and could report missing/rogue data in
situations where measurements are insufficient (e.g., wire
damage). SWaP-C could further be reduced with tighter inte-
gration of IMA with display and power distribution functions.
Commonality in tools, IO models, and architectures should
be leveraged. Reconfiguration can reduce platform size and
increase availability by reallocating resources temporarily.
Current approaches struggle with scenario explosion in cer-
tification [7]. Enabling certification frameworks and formal
methods are missing.
B. Safety-critical Commercial-Off-The-Shelf (COTS)
Today, most platform modules are custom developed for a
single platform. COTS hardware (HW) with associated certi-
fication artifacts could improve portability and decrease cost,
allowing manufacturers to reuse technology developed within
one program in other domains, e.g. high power switching
and dual-lane IMA devices [8]. However, additional effort is
required since tool environments differ, which must be tailored
to specific HW features. For instance, HW or Operating
System (OS) configuration tools are usually not generic.
An ARINC 653 compliant COTS OS aims at providing
modular certification that can be reused. However, in practice,
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
every new aircraft presents significant differences in configura-
tion, HW compatibility, development environment, etc. Along
with the inevitable new features for a new product, adaptations
of existing certification artifacts as well as development of
new artifacts are forced. Thus, finding a practical approach
for reusable modular certification is a challenge that DO-297
does not sufficiently address.
C. Operating Systems and Middleware
Operating Systems and Middleware (MW) increase reuse of
avionics SW, e.g., standardized MW for redundancy manage-
ment. [9] The general conflict between standardization with
approved certification artifacts and customization is addressed
by initiatives such as Modular Open System Architectures
(MOSA) [10] and the FACE standard developed by a con-
sortium of government, industry and academia, combining
existing SW standards (ARINC653, POSIX, DDS) [11] for
a segmented operating environment with interchangeable OS
and MW components, similar to iOS or Android. Moreover,
connectivity within aircraft systems and to the Internet is
bringing cyber-security requirements into formerly isolated or
air-gap protected avionics systems. Continuous airworthiness
requires permanent monitoring for security threats and their
safety impact, as discussed in Sec. VII-A and [12]. Also,
the transition to multi-core processors and to architectures
other than PowerPC creates challenges for OS and MW layers.
Parallel execution of applications introduces interference that
complicates the demonstration of determinism and partitioning
as discussed in Sec. VI-A. A way forward are new processor
features such as IO Memory Management Unit (IOMMU),
performance counters, or cache partitioning that can be lever-
aged both for verification, and at run-time for partitioning or
fault containment [13]. Virtualization as detailed in Sec. VI-C
can be used by OS and MW to enable rehosting of previously
developed applications on new architectures [14].
D. Self-organizing Avionics
The human labor of configuration could be eliminated
with self-organizing platforms. Self-organization means that
computers detect peripherals, organize work share, and ensure
safety and security. Moreover, doing so during operation
could increase safety margins by reconfiguration capabilities.
Technological feasibility was shown in a less-critical cabin
domain [15]. Safety-critical applications lack deterministic al-
gorithms for self-organization and self-proofing. First attempts
were made for topology verification [16]. However, self-
organization contradicts current approaches to certification. A
way forward could be that the platform mimics the behavior
of a certification authority. Trust could be provided by the
evidence that the platform can provide any certification item
in any state.
III. R EQUIREMENTS E NGINEERING
Requirements Engineering (RE) is the process of develop-
ment and maintenance of requirements, and is expected in the
guidelines ARP-4574A for aircraft and system development,
DO-254 for HW, and DO-178C for SW. A major challenge
is the assurance of requirement quality, i.e. identification of
defects like incompleteness, inconsistency, and ambiguity, but
also to identify errors like undefined conditions and missing
quantification.
Development efficiency, analysis/review effort, and testing
are influenced by the quality of the requirements. Therefore,
the following sections present current approaches in capturing
requirements that promise to ensure quality. Only approaches
that enable automation in RE are considered.
A. Natural Language Processing (NLP)
Requirements in industry are mostly captured in text. Ex-
ample tools for requirements management include DOORSTM ,
Jama ConnectTM , and Microsoft® Word. Natural Language
Processing (NLP) is an approach for automated textual de-
composition and analysis of man-made textual requirements.
First successful applications utilizing NLP are available for
automated quality assurance of requirements [17], for in-
stance the assurance of INCOSE criteria and compliance to
ISO/IEC/IEEE 29148:2011. NLP can also help classify and
cluster requirements, extract key abstractions, generate models,
and traceability. Starting from these visions, a comprehensive
summary of NLP challenges in RE were identified in the
NLP4RE 2018-workshop [18]: (1) Not enough input data is at
disposal for academic researchers to evolve single NLP tasks.
Examples of requirements and their manual appraisal, e.g.
identification of defects or its classification, is required for the
training of NLP techniques. (2) NLP experts, RE researchers,
tool vendors, and industry representatives do not sufficiently
cooperate. Tailoring of NLP to the needs of the user, for
instance by compensating a small number of provided data by
incorporating domain-specific conditions, could reduce com-
plexity in NLP applications for specific industries. (3) Domain-
specificity is not sufficiently considered in NLP techniques.
Understanding of the mutual effects between diagrams, figures,
and textual requirements can contribute to capturing implicit
knowledge. Moreover, domain-specific ontologies can bring
great value to the extension of the natural language considered
in public NLP.
Joint project reports by industry and academia are available
on the interplay of NLP and RE. The research efforts con-
centrate on enhancement of NLP for quality assurance [17],
such as detection of ambiguity, comparatives, loopholes, neg-
ative terms, non-verifiable terms, pronouns, subjectivity, and
superlatives. However, these techniques lack in exploiting
domain knowledge. Tailored parsing rules incorporating defini-
tion of domain-specific glossaries and ontologies need further
advances.
B. Controlled Natural Language (CNL)
CNL goes beyond quality assurance of requirements as
this technique applies certain rules for textual requirements:
grammar, syntax, semantics, and structure. Besides quality
assurance by suppressing adverse terms and expressions [19],
[20], CNL can enable the deduction of formal specifications
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
e.g. by using logical expressions [21] and can even generate
design models [22].
Successful production tools are already available [23], but
a hindrance in their use is the significant effort creating glos-
saries, ontologies, and adapted patterns. There is no common
database of patterns or ontologies. Another weakness is that
expressiveness is restricted by the finite set of patterns, i.e.
remaining requirements might not be representable in the tool.
C. Formal Specification
Formal specifications facilitate compliance between require-
ments and the design. For the most of them, the created
specification can directly be utilized as inputs to formal
verification techniques, model-checking, and theorem prov-
ing (see Sec. V). With property-oriented techniques, such
as Larch [24], OBJ [25], and Common Algebraic Specifi-
cation Language [26] the specification is expressed by log-
ical statements with algebraic semantics, e.g. based on set
theory. These specification languages are declarative formal
languages. Model-oriented techniques, such as Vienna Devel-
opment Method [27], Z [28], and B [29] provide the necessary
language constructs to specify the behavior of an operation on
an abstract, often declarative level, i.e. without stating how
the system shall do it. A possibility is to state pre- and/or
post-conditions. Frequent constructs of processes in embedded
systems are best captured with process algebra techniques, i.e.
the Calculus of Communicating Systems [30], e.g. Commu-
nicating Sequential Processes [31] and π-calculus [32]. With
Promela [33] it is possible to specify sequential and concurrent
programs.
The main hindrance is the formalization of requirements in
formal languages, that is in itself prone to errors and requires
specific education of the engineer.
D. General Requirements Engineering Challenges
Besides missing domain-specificity of most considered tech-
niques, all approaches lack a connection to avionics-specific
physical models often created during the development of the
system’s functionality. The missing measurement for overall
requirements quality was identified as a further root cause
for challenges during the AvioSE’19 workshop [5]. These
measurements exist for some of the above mentioned quality
criteria, but are in general considered incomplete. During the
mentioned workshop also the lack of knowledge in RE was put
in focus. Finally, current empirical studies into waste due to
inefficient RE could boost acceptance for future improvements,
by providing reliable estimates of current wasted human
resources or numbers of defects traced back to RE.
IV. M ODEL - BASED D EVELOPMENT
Model-based based systems engineering (MBSE) is the
utilization of models in systems development. Objectives are
to speed up development steps, encapsulate complexity and
increase design maturity via early functional validation. In
general, models provide a graphical representation, which
can be understood naturally, are more rigid than text, and
validatable through use of model testing. In model-driven
engineering model formats are defined and machinable. In
model-integrated computing SW is completely composed au-
tomatically from models [34]. The following is a summary of
MBSE applications in avionics.
A. General Purpose Modeling Languages
There are two categories of modeling: (1) Architecture
models depict structure, behavior, and system integration,
e.g. at the IO level. Model languages originate from SW
development, mostly based on the Unified Modeling Language
(UML), which describes class or component dependencies,
as well as discrete or logical behavior. A systems engi-
neering extension is SysML. Majorly used in avionics are
class diagrams and state machines. In addition, more specific
languages were derived for avionics, e.g. the Architecture
Analysis and Design Language (AADL), ARCADIA, and
System Composer. AADL is a general system architecture
language providing avionics extensions [35]–[37]. Arcadia was
developed as alternative to SysML, implemented by Thales
in the open source tool Capella. In March 2019, Mathworks
released System Composer, based on their existing Simulink
model constructs. (2) Physical models represent time-related
physical behavior. Physical models are common for aircraft
systems, but not for avionics.
B. Domain-specific Modeling
Domain-Specific Modeling (DSM) is the creation of cus-
tomized, formally defined, model formats. A Meta-Modeling
Language (MML) defines the structure of a Domain-Specific
Language (DSL). The formal nature inherently allows ma-
chine processing and validation. DSM is extensively applied
in aerospace for customized structural models that simplify,
streamline, and automate development steps, e.g. configuration
management [38], avionics platform design, and optimization
([39], [40]), and development data management [41], resulting
in significant time savings, fewer errors, and improved under-
standing. With Meta Object Facility (MOF) there is a well-
defined meta-modeling standard. Frameworks like Eclipse
Modeling Framework (EMF) and Generic Modeling Envi-
ronment (GME) are well established. Those tools, however,
are generally kept out of the qualification path, because their
impact on qualification is unclear and the frameworks (and
all derived tools) are usually considered unqualifiable. Many
originate from non-profit non-avionics communities.
C. Model Transformation
DSLs of avionics systems allow for automated transforma-
tion between models. For instance, an avionics architecture
model from pre-design can be converted to an Interface
Control Document (ICD), application code, and configuration
data [42]. Model Transformation Languages (MTL) describe
transformations formally. Examples are XSL Transformation
and Query View Transformation. An efficient use, however,
requires all models to be defined with the same MML and
framework. Moreover, the level of abstraction is high and
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
understanding often difficult. Graphical MTL are more in-
tuitive to read. They describe transformations in diagrams
similar to the model itself, e.g. GREAT and Eclipse Henshin,
but their development is not finished. The major challenge
is to convince certification authorities to allow credit for
transformation methods. There is no formally proven model-
transformation language.
D. Code and Qualification Artifact Generation
The earliest application of model-driven engineering in
avionics is the generation of SW. It was first matured by
ANSYS SCADE, which generates qualified source code and
documents. Generation is, however, restricted to SW interfaces
with no physical interaction and no concurrency. Both exist
in reality, thereby causing additional effort in development,
testing, and qualification by wrapper code and configuration.
A zero-effort model-to-product generation seems impossible,
because HW dependencies cannot be considered in necessary
detail in any physical model today. If, however, the HW is
restricted and a unifying SW layer is introduced that guarantee
a defined behavior, an almost complete qualifiable generation
is possible. This is demonstrated with the Flexible Avionics
Platform and the AAA process [43]. Implementations, tests,
and qualification documents are generated with model trans-
formations. In this case, generation is not qualified, because
the resulting documents are equal to a human development
process. Two CS-23 fly-by-wire systems were developed with
AAA [44], [45]. Acceptance lacks a completed qualification
process. This work is ongoing. A lesson learned is that
generated documents tend to be more detailed and difficult
to read than documents created by humans.
E. Early Validation
Validating system functions on avionics platforms happens
late although SW is developed in parallel to HW, because
final testing depends on the HW being physically available.
Moreover, the increasing number of system functions and their
interoperability account for hidden failures due to the coupling
with the avionics platform, which is hard to assess and often
result in gaps in the specification. Methods for early validation
are desired that simulate abstract platform and system models
to test functional and timing behavior in a virtual integration
based on operational scenarios. MBSE provides means to
validate model functionality prior to generating the code. A
challenge is achieving the necessary level of detail of the
avionics platform model [36], I/O [46], the system functions,
and the emulated equipment. Furthermore, the number of inter-
connections, states, and failure modes increases exponentially,
the more system functions are taken into account. Efficient and
automated simulation generation, parametrization, testing, test
script and documentation generation (e.g. using model trans-
formation techniques) are needed. Blind spots can be identified
using scenario-based testing in addition to requirements based
testing. Modeling standards and tool chains are required that
support early validation methods. First steps are presented
in [47].
 V. AUTOMATED V ERIFICATION
Automated verification aims at machine-based detection of
defects due to specification or implementation errors through-
out the development process. Approaches applied in avionics
are described in this section.
A. Virtual Verification
Due to tighter development cycles, an improvement in
the identification and correction of defects is an ever-lasting
desire. The earlier defects are identified in the development
process, the less expensive is their correction [48]. However,
dynamic test methods are only applicable after the complete
implementation of the SW. In other words, these tests are
conducted rather late in the development process.
Schamai et al. [49] present an approach, which allows
for the verification of the system design against the system
requirements, i.e. at the very beginning of the development
process. They suggest the following steps:
• Requirements selection: Out of the available textual re-
quirements those are selected manually that are amenable
for formalization.
• Requirements formalization: Properties to be checked
automatically are extracted manually from the selected
requirements. Furthermore, corresponding models for
monitors1 are created.
• Design model creation and selection: Particular design
artifacts2 , which correlate with the selected requirements,
are created and chosen.
• Linkage between requirements and design model prop-
erties: For connecting the properties of both the require-
ments and the design models, appropriate test models are
created.
• Observation of potential requirement violations: While
the created models are executed, potential violations are
identified, and reported by monitors.
While the desire to verify artifacts in the development
process as early as possible is valid, the described approach
involves a considerable amount of additional manual work.
Since in particular the description of properties is not a trivial
task, a lot more automation is necessary. In addition to this, the
monitor specification is still a considerable challenge. The au-
tomatic deduction of such monitors from formal requirements
could alleviate their application in industry.
B. Theorem Proving
The specification of software functionality can be conducted
using formal languages like FOCUS [52] with its well-defined
and executable semantics. This language describes compo-
nents with hierarchical structure using several semantically-
equivalent notations. In particular, the proposed graphical no-
1 A monitor (or observer) checks the potential violation of the modeled
properties.
2 The model is designed using the language ModelicaML [50]. ModelicaML
enriches the modeling language Modelica [51] with UML’s graphical notation
by providing a UML profile.
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
tation extends established ones [53] and can also be transferred
to e.g. sequence diagrams [54].
FOCUS and its accompanying modeling tool Auto FOCUS
3 [55] has seen a wide acceptance in academia [56]. In
particular, Kriebel et al. [56] present an approach for trans-
lating FOCUS models created in a tool [57] to an Isabelle
automaton specification, which in turn is mapped to a set of
functions processing streams. This transformation allows for
the verification of properties by the application of the theorem
prover Isabelle [58]. Nevertheless, there are still some issues to
be dealt with, before this approach fits for a wide application
in industry [56]:
• Improved tool support
• The robustness and level of automation of the proof
functionality have to be increased. In particular, the
formal verification should be hidden completely from
the developer. This in turn allows for a continuous
verification, as the underlying idea behind this approach
is already state-of-the-art for continuous integration [59]
and delivery [60].
Though Isabelle has already been used successfully in
proving the correctness of a micro-kernel scheduler [61],
the correctness of the proof is dependent on the correctness
of Isabelle and its implementation. Kunčar [62] proved the
completeness and correctness of a part of Isabelle’s code.
However, there are still Isabelle elements to be proved.
Hoare’s calculus [63] provides the foundation for tool
implementations supporting programming languages such as
C (Frama-C, [64]) or Ada (SPARK, [65]). Though such tools
have already been deployed successfully in industry [66]
according to DO-178C and its supplement DO-333, theorem
provers need the (possibly error-prone) user-interaction with
the provision of additional input in the form of lemmas
and also a highly-elaborated specification of properties to be
verified.
C. Model Checking
Model checking [67] is defined as an automatic method
for the verification of a model with respect to a specification
expressed in a mathematically-sound language. Since the com-
plexity of software is rising continuously, the state space of
both the model and its specification is increasing as well. This
state explosion reduces the scalability of this approach.
In order to get around this issue, Esparza and Heljanko [68]
use partially ordered graphs instead of deploying state transi-
tion systems. This unfolding approach has seen considerable
improvements after its original presentation [69]–[71], which
checked only the reachability of states and identified possibly
existing deadlocks. Now unfoldings are e.g. amenable to
properties expressed in Linear Temporal Logic and supported
by various tools (see e.g. [72]).
Though the presented approach is very promising, its suit-
ability for an application in industry needs to be confirmed. In
particular, the time and space efficiency of the implemented
verification algorithms has still to be demonstrated [68].
 VI. E MERGING T ECHNOLOGIES
Avionics depends on HW of the general information tech-
nology domain. The increasing technological progress induces
challenges especially in processors, communications, OS, and
displays.
A. Multi-core CPU
Moore’s Law and a frequency limit at approximately 4
Ghz result in an increasing number of cores per processor.
What scales well in general IT “complicates control and adds
significant challenge to assurance analysis, because multiple
partitions can now run simultaneously on different cores and
thus might interfere with one another more directly than
on single-core systems, where partitions must run one at a
time” [73] in avionics. The key challenge is bounding the
Worst Case Execution Time (WCET), particularly cross-core
interference for memory resources and data paths e.g. for PCIe
and CPU interconnects. Unbounded interference jeopardizes
the ability to provide a consolidated platform as safe as
equivalent federated systems [74]. Additional challenges come
with hidden, or non-static microcode. The position paper
CAST-32A makes remarks on the certification for multi-core
processors, but there are currently no certification guidelines
nor common agreements about necessary design steps and the
dependability level of tests. Simplifications can be achieved
with fully open processor architectures (e.g. ARM, RISC-V)
or safety nets.
B. Advanced network technology
Substituting proprietary and single-purpose avionics busses
with open, general-purpose COTS communication systems
can greatly reduce SWaP-C. Historically, COTS networks
(e.g. Ethernet) lacked predictability and determinism. Special
solutions as ARINC 664 – a rate-constrained avionics Ethernet
– were developed, which are very successful, but also costly
due to the limited market. A transition to COTS Ethernet might
be feasible with the emerging Time Sensitive Networking
(TSN, IEEE 802.1Q-draft) standard. TSN standardizes time-
scheduled traffic and provides time-synchronization (IEEE
802.1AS-rev) like TTP and TTE. TSN is superior to A664
in determinism and performance, while using low-cost COTS
components. Open issues are, however, HW certification,
redundancy, and a significantly higher configuration effort for
time-synchronized networks. Besides protocols, novel physical
and application layers are under consideration in avionics.
Power-line communication introduces new possibilities to save
weight. However, taking safety (redundancy) or security into
account, it makes the design harder by introducing addi-
tional configuration parameters [75]. Optical transportation
is immune to interference and lightweight, but lacks active
switching capabilities, long-term experience, and configurabil-
ity. Network configuration can be simplified with data-centric
solutions such as publish-subscribe or message queues. A
certified solution is a variant of DDS [76], which, however,
currently lacks a wide application, perhaps due to obscuring
configuration parameters within application software.
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
C. Virtualization and Containers
Partitioning is expected by IMA and required by ARINC
653. Virtualization abstracts computing HW so that it ap-
pears as a virtual resource. A hypervisor hosts multiple guest
operating systems (GOS), innately providing partitioning by
managing the computing HW in lieu of the hosted software.
Virtual vessels called domains or partitions are serviced by
a virtual machine running on one or more processor cores.
Separation is enforced with a timer that can interrupt the
current thread of execution and a Memory Management Unit
(MMU) that segregates pages of memory. Thus the entire GOS
is partitioned with respect to time and space. In some cases
separation of IO is also done by an IOMMU. These HW mech-
anisms are guarded from GOS manipulation via hierarchical
protection rings. Since virtualization provides time and space
partitioning implicitly, it is a natural fit for the partitioning
needs of avionics platforms. Moreover, certification is simpli-
fied since file systems, network protocol stacks, and graphical
user interfaces are untouched as they are part of the GOSs. On
the other hand, the specific Application Programming Interface
(API), communication mechanisms, and health monitoring
dictated by ARINC 653 must be developed or added [77].
In addition, virtualization adds a small performance overhead.
Current measures state 1 to 20% [78], but this does not cover
the safety-critical domain and needs further investigation. For
example, determinism and non-interference properties required
for safety might require expensive cache flushing during a
partition switch. Performance issues can be addressed with
containers (e.g. Docker). Containers partition at the OS level
and do not require HW virtualization extensions. They are
light-weight in terms of source code size and performance
impact. However, isolation is harder to assure without the
HW enforced separation of GOS. Currently, no approach is
known using containers to isolate mixed-criticality software in
an avionics system. However, a number of research projects
test containers to enable more rapid development, e.g. [79].
As hypervisor performance continues to improve, a hypervisor
based container approach such as KATA might be more
appropriate for avionics.
D. Glass cockpit
Over the past few decades, the glass cockpit has evolved
from separate displays, to a combined display system con-
sisting of a suite of heads-up, heads-down, and smaller an-
cillary displays shared between system functions. Currently,
touchscreen technology is transitioning into the cockpit [80].
Moreover, tablets became a standard flight aid in the cockpit.
Novel approaches add touch to the fixed displays, such that
physical controls can be eliminated and replaced with soft on-
screen controls. The latter can be replicated in many places.
However, care must be taken as this flexibility can lend diffi-
culty in remembering control location. Moreover, existing user
interfaces are not optimal for touch/gesture controls and must
be redesigned. The physical position of displays may need to
be closer to the crew and angled to reduce crew fatigue. As
display content increases, curved screen technologies should
be investigated to extend the display area in the inherently
curved flight deck environment. The future is intriguing:
Wearable displays with augmented reality could provide a
tremendous field of view not attainable in traditional heads-
up displays. Transparent displays are entering the consumer
electronics industry and could eventually be integrated with
aircraft windows to provide augmented visuals.
VII. E MERGING D EMANDS
New usage scenarios, as well as workload and cost re-
duction demand new avionics capabilities. Most challenging
seem security, artificial intelligence (AI) integration, and crew
reduction.
A. Security
While safety addresses faults, security prevents malicious
attacks. While safety assessment is routine in aerospace, secu-
rity struggles mainly with lack of quantification, standardized
representations, overall system knowledge, and hidden inter-
domain links [81]. In a case study, Teso [82] highlighted
several security vulnerabilities in the Aircraft Communications
Addressing and Reporting System and the flight control sys-
tem, e.g. message jamming and eavesdropping. Availability,
confidentiality, integrity, and authentication are not imple-
mented in the communication system [83]. Rising connectivity
emphasizes the above issues.
A semi-formal notation for security is UMLsec [84], which
is a UML profile for the development and analysis of security-
critical systems. UML is extended with annotations for the
specification of security requirements. The integrity of the
designed system model is ensured, if no constraints in the
UMLsec model are violated during simulated attacks. How-
ever, there is currently no means for confirming, whether
the set of simulated attacks is sufficiently complete. This
remains a key challenge with security, since testing against
known attacks is not a good indicator of robustness against
future (as yet unknown) attacks. While UMLsec is a passive
countermeasure, Crane [85] suggest an active approach, where
booby trapping inserts countermeasures automatically into the
software. This approach is feasible for desktop applications,
but the following issues prevent deployment in safety-critical
real-time software:
• Missing functional and temporal equivalence of the soft-
ware with and without booby traps
• Missing deterministic and reliable identification of mali-
cious attacks
In general, formally proven software (see Sec. V) has some
promise for guaranteeing reliability even for yet unknown
cyber-security attacks, because formal methods can mathemat-
ically prove immunity to entire classes of attacks, not just
specific instances of test cases. However, the high cost of
formal methods is still prohibitive.
B. Artificial Intelligence
While the main workload of an aircrew was dedicated to
flying the aircraft one or two decades ago, nowadays pilots
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
spend most of their time dealing with mission success. This
shift has been accomplished by increasing the degree of
automation and carefree handling of the aircraft. Due to rising
mission complexity the workload will continue to increase in
future, driving automation of the execution of missions as well.
The incorporation of artificial intelligence (AI) could help.
The same applies for the development of avionics systems,
where engineers could benefit from automation through AI
algorithms. First approaches can be seen in NLP, but validation
and verification could be additional topics.
Machine learning as a subset of AI comprises simple neural
networks and deep neural networks [86]. While simple neural
networks contain only one layer between input and output,
deep neural networks [87] consist of several hidden layers. The
latter have already been deployed successfully in a setting with
considerable complexity [88]. Substantial progress has also
been reached in the context of safety-critical applications [89],
resilience [90], and dependability [91] of neural networks.
However, it can still be demonstrated that adversarial exam-
ples [92] have negative impact on the dependability of this
technology.
Though AI is already applied in non-safety-critical areas,
major advancements are yet necessary. Up to now verification
is impossible to prove, due to the difficulty of determining why
a given neural network has come to a certain decision. Having
a way to demonstrate this is a matter of uttermost importance
for the certification of a product in the avionics domain.
C. Pilot-reduced/less Cockpit
Reducing the number of pilots in the cockpit is a logical
consequence of reducing operation costs. Single, remote or no-
pilot operation have organizational, social, and technical chal-
lenges ([93], [94]). From the avionics perspective the general
issue is: today pilots are the final authority in critical situations.
Removing even one pilot changes the situation: A healthy
pilot has an incapacitation probability of 10−6 1/h [95].
This is insufficient. Therefore, the avionics system must be
able to take over the final decision and new systems or
the combination of avionics and a pilot must have a failure
rate less than 10−9 1/h. Three significant avionics platform
challenges are:
• In single pilot operation a reliable redundant system
composed of human and avionics can only be achieved,
if the pilot’s integrity is known by the avionics through
reliable incapacitation detection devices.
• In remote pilot operation requires a low-latency, high-
integrity, high-availability (10−9 1/h) secured global
coverage civil aerospace data link. Neither a suitable
technology nor a global platform are hardly available
today.
• Fully autonomous operation requires new autonomy func-
tions, such as air traffic control negotiation, system su-
pervision, minimal equipment list management, fuel and
flight-plan supervision, recovery, and emergency plan-
ning [96]. Autonomy functions will be more complex and
require significantly more computational power. This will
 emphasize today’s lack in complex (AI) function and high
performance hardware (multi-core) certification.
In any case a more sophisticated interaction between pilots
and automation is required. This includes visualization tech-
nology, control interfaces, and self-explanation of algorithmic
decisions. It must be clear: Who is in control, why, and what
they are doing? Moreover, this human-machine interaction
must be an integral part of a suitable qualification process.
VIII. D ISCUSSION AND WAYS F ORWARD
All aspects of avionics exhibit individual challenges. Nev-
ertheless, there are some general issues, which are suggested
to be addressed as follows:
(1) Many challenges are related to complexity. Avionics
platforms, SW, and HW become too complex to be fully
gathered by a human’s mind, such that it is a real effort
to derive complete verification tests and documents as it is
desired by the certification processes. Moreover, the number of
stakeholders in the development and distribution of knowledge
rises. This can be addressed in two ways. First, by making it
manageable in suitable models and, second, by the automation
of development steps. Domain-specific languages and trans-
formations are good tools for managing complexity. Their
applications, however, lack mature tools and visualization of
large structural model data. → Effort should be spent in further
developing modeling tools and methods such that they are
applicable to avionics development processes and could even
be used in certified tools or SW. The efficient and reliable
visualization of complex system structures becomes inevitable
in future but must be advanced.
(2) Automation is provided by NLP, transformations, and
formal methods. All, however, lack trust. Humans are natu-
rally skeptical of automated results and the tools generating
those results and automation algorithms are bad in explaining
results. → Effort must be spent in finding out what evidences
automation should produce in order to make it trust-worthy
and eligible for certification credits.
(3) Trust is also a matter of education. IT is important in
avionics, yet the majority of aircraft engineers are (and want
to be) trained as mechanical engineers. Computer scientists on
the other hand have less understanding in avionics develop-
ment, qualification, and certification. Although they might be
aware of methods that help, they do not know how the avionics
domain could benefit most from these methods. → Knowledge
on modeling, transformation, formal checkers, and security
must be emphasized in education, such that young engineers
(and certification agents) know the expectable results and
drawbacks of a broad range of useful methods. Since it is
surely not the only skill needed in avionics, an option might be
that the general aerospace student can opt for a specialization
in ”digital systems engineering”.
(4) The broad range of methods is another field for improve-
ment. There is no one-size-fits-all method, but a combination
can cover a significant portion of current issues. However,
most methods are developed and advertised in their community
and interfaces between methods are bad. → It should be
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
investigated what is the best combination of methods that
could cover most development aspects. Moreover, standardized
method interfaces should be defined, covering requirements,
models, transformations, and equations and allow for a seam-
less integration.
(5) Another significant hurdle in certification is HW/SW
dependency. System tests have to be carried out on real
hardware. Virtual testing is not possible due to insufficient and
non-qualified simulations, and reuse in terms of qualification
is very restricted due to missing standards at the HW/SW
interface. → Research should be carried out on reliable HW
simulation technology as well as on a resilient abstraction of
HW behavior.
(6) New technologies evolving in processing, graphics,
networks, new vehicles, and vehicle automation do not bring
very different challenges, but will exponentially emphasize the
existing ones. Moreover, there is a gap between progress of
general IT and its adaptation in avionics that could increase up
to a point where there is no overlap anymore. The aerospace
industry is too small to develop their HW completely alone
and neither customers, pilots nor passengers would understand
that. → Effort in teaming up with other safety-critical cyber-
physical system domains seems inevitable. The point in time
is almost perfect, since autonomous car developers begin to
realize that they have to go for an aircraft-like certification
process, but for their SW and HW this seems almost infeasible.
Likewise for UAV, IoT, space, rail, and nautical domains. How-
ever, this must be fostered by appropriate research projects and
a willingness from all domains to develop common results and
to define and use domain-wide standards.
IX. C ONCLUSION
Avionics are mandatory in current flying vehicles and their
importance and performance expectations will rise in future.
Engineers already struggle with the complexity of systems,
SW, HW, and a heavily manual certification process. Addi-
tional hot topics are the inevitable change to multi-core proces-
sors, high-bandwidth busses, active security, and autonomous
transportation. Ways forward are modeling, development au-
tomation, and the adaptation of IT standards, virtualization,
TSN, and touch inputs. Methods that allow the efficient
development of future autonomous systems are available with
formal and computer-aided requirements engineering, domain-
specific modeling, graphical model transformations, theorem
proving, simulation, and test/code/document generation. How-
ever, there is a significant lack of trust, integration, compat-
ibility, education, and implementation of such methods that
prohibit a straightforward application today. It is suggested to
foster the research and academic and industrial cooperation
in these areas; namely define a method combination, create
qualifieable implementations, and enshrine them in aerospace
education. It seems inevitable, moreover, to team up with other
domains to achieve a critical mass in method and hardware
development. Any progress in these areas is encouraged and
the authors are open for cooperation.
 Future updates of this article are anticipated. The idea
is to take it as a baseline and document progress as it is
made in the individual areas. Moreover, avionics are broader
than discussed in this article. Areas, which must be covered
in future include cabin electronics and secure programming
languages.
ACKNOWLEDGMENT
We thank Andy Bellis from Collins Aerospace for his
contributions and review of this article.
R EFERENCES
[1] R. Collinson, Intro. to Avionics Systems, 2nd ed. Springer, 2011.
[2] P. Bieber, F. Boniol, M. Boyer, E. Noulard, and C. Pagetti, “New chal-
lenges for future avionic architectures,” AerospaceLab, vol. 4, no. 11,
May 2012.
[3] A. Goodloe, “Challenges in the verification of flight-critical systems,”
in CPS V&V I&F Workshop, Pittsburgh, USA, 2014.
[4] T. Gaska, C. Watkins, and Y. Chen, “Integrated modular avionics - past,
present, and future,” IEEE Aerospace and Electronic Systems Magazine,
vol. 30, no. 9, pp. 12–23, Sept 2015.
[5] B. Annighoefer, A. Schweiger, and M. Reich, Eds., 1st Workshop on
Avionics Systems and Software Engineering, 2019.
[6] C. B. Watkins and T. Burns, “Evolution of the systems integrator role and
change management process within highly integrated aircraft systems,”
in 2015 IEEE/AIAA 34th Digital Avionics Systems Conference, Sept
2015.
[7] P. Bieber et al., “Preliminary design of future reconfigurable IMA
platforms,” SIGBED Rev., vol. 6, no. 3, pp. 1–5, 2009.
[8] B. Kornek-Percin, “New IMA architecture approach based on ima
ressources,” in 2015 IEEE/AIAA 34th Digital Avionics Systems Con-
ference, Sept 2015, pp. 1–19.
[9] B. Luettig et al., “A service provisioning layer enabling simplex-minded
function development on integrated modular avionics hardware,” in IEEE
37th Digital Avionics Systems Conference, 09 2018.
[10] J. Tokar, “A comparison of avionics open system architectures,” ACM
SIGAda Ada Letters, vol. 36, pp. 22–26, 05 2017.
[11] M. Garcı́a-Valls et al., “Using DDS middleware in distributed partitioned
systems,” ACM SIGBED Review, vol. 14, pp. 14–20, 01 2018.
[12] A. Baker and P. Parkinson, “Cyber security enhancements for a safety-
critical arinc 653 avionics platform,” in Twenty-sixth Safety-critical
Systems Symposium, York, UK, 2 2018.
[13] L. H. Mutuel et al., “Assurance of multicore processors in airborne
systems,” FAA, Tech. Rep. DOT/FAA/TC-16/51, 2017.
[14] D. Radack, H. G. Tiedeman Jr, and P. Parkinson, “Civil certification of
multi-core processing systems in commercial avionics,” in 27th Safety-
critical Systems Symposium Proceedings, 02 2019.
[15] B. Annighoefer, M. Riedlinger, O. Marquardt, R. Ahmadi, B. Schulz,
M. Brunner, and R. Reichel, “The adaptive avionics platform,” IEEE
Aircraft Electronics Systems Magazine, 2019.
[16] B. Schulz and B. Annighoefer, “A verification algorithm for the
automatic topology discovery of the adaptive avionics platform,” in
IEEE/AIAA 37th Digital Avionics Systems Conference, London, UK,
Sep. 2018.
[17] H. Femmer, D. Méndez Fernández, S. Wagner, and S. Eder, “Rapid
quality assurance with requirements smells,” Journal of Systems and
Software, vol. 123, 03 2016.
[18] F. Dalpiaz, A. Ferrari, X. Franch, and C. Palomares, “Natural language
processing for requirements engineering: The best is yet to come,” IEEE
Software, vol. 35, no. 5, pp. 115–119, Sep. 2018.
[19] C. Denger, D. M. Berry, and E. Kamsties, “Higher quality requirements
specifications through natural language patterns,” in Proc. 2003 Sympo-
sium on Security and Privacy, Nov 2003, pp. 80–90.
[20] G. Génova, J. M. Fuentes, J. Llorens, O. Hurtado, and V. Moreno, “A
framework to measure and improve the quality of textual requirements,”
Requirements Engineering, vol. 18, no. 1, pp. 25–41, Mar 2013.
[21] M. Autili, L. Grunske, M. Lumpe, P. Pelliccione, and A. Tang, “Aligning
qualitative, real-time, and probabilistic property specification patterns
using a structured english grammar,” IEEE Transactions on Software
Engineering, vol. 41, no. 7, pp. 620–638, July 2015.
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
[22] L. Lúcio, S. Rahman, S. bin Abid, and A. Mavin, “EARS-CTRL:
Generating controllers for dummies,” in MODELS, 2017.
[23] The Reuse Company. (2019) Systems engineering suite.
[24] J. V. Guttag and J. J. Horning, Larch: Languages and Tools for Formal
Specification. Berlin, Heidelberg: Springer-Verlag, 1993.
[25] J. Goguen, C. Kirchner, H. Kirchner, A. Mégrelis, J. Meseguer, and
T. Winkler, “An introduction to obj 3,” in Conditional Term Rewriting
Systems, S. Kaplan and J. P. Jouannaud, Eds. Berlin, Heidelberg:
Springer Berlin Heidelberg, 1988, pp. 258–263.
[26] E. Astesiano, M. Bidoit, H. Kirchner, B. Krieg-Brueckner, P. D. Mosses,
D. Sannella, and A. Tarlecki, “Casl: the common algebraic specification
language,” Theoretical Computer Science, vol. 286, no. 2, pp. 153 –
196, 2002, current trends in Algebraic Development Techniques.
[27] I. J. . Joint Technical Committee, Information technology — Program-
ming languages, their environments and system software interfaces —
Vienna Development Method — Specification Language — Part 1: Base
language, ISO ISO/IEC 13 817-1, 1996.
[28] S. S. . Joint Technical Committee ISO/IEC JTC 1, Information tech-
nology, Information technology — Z formal specification notation —
Syntax, type system and semantics, ISO ISO/IEC 13 568:2002, 1996.
[29] J. Abrial and J. Abrial, The B-Book: Assigning Programs to Meanings.
Cambridge University Press, 2005.
[30] R. Milner, A Calculus of Communicating Systems. Berlin, Heidelberg:
Springer-Verlag, 1982.
[31] C. A. R. Hoare, Communicating Sequential Processes. New York,
NY: Springer New York, 2002, pp. 413–443. [Online]. Available:
https://doi.org/10.1007/978-1-4757-3472-0 16
[32] R. Milner, Communicating and Mobile Systems: The Pi-calculus. New
York, NY, USA: Cambridge University Press, 1999.
[33] M. Ben-Ari, Principles of the Spin Model Checker, 1st ed.
[34] J. Sztipanovits and G. Karsai, “Model-integrated computing,” Computer,
vol. 30, no. 4, pp. 110–111, April 1997.
[35] J. Delange, L. Pautet, A. Plantec, M. Kerboeuf, F. Singhoff, and
F. Kordon, “Validate, simulate, and implement ARINC653 systems using
the AADL,” in Proc. of the ACM SIGAda annual Intl. conference on
Ada and related technologies, ser. SIGAda ’09. New York, NY, USA:
ACM, 2009, pp. 31–44.
[36] M. Lafaye, M. Gatti, D. Faura, and L. Pautet, “Model driven early
exploration of IMA execution platform,” in Digital Avionics Systems
Conference, 2011 IEEE/AIAA 30th, oct. 2011, pp. 7A2–1 –7A2–11.
[37] Z. Li, S. Wang, and T. Zhao, “A model based simulation verification
method for IMA reconfiguration on system level,” in 2015 First Intl.
Conference on Reliability Systems Engineering, Oct 2015, pp. 1–5.
[38] M. Halle and F. Thielecke, “Next generation IMA configuration engi-
neering - from architecture to application,” in 2015 IEEE/AIAA 34th
Digital Avionics Systems Conference, Sept 2015, pp. 6B2–1–6B2–13.
[39] B. Annighoefer and F. Thielecke, “A systems architecting framework
for distributed integrated modular avionics,” in Deutscher Luft- und
Raumfahrtkongress, Augsburg 16. - 18. Sept. 2014. Augsburg: Deutsche
Gesellschaft fuer Luft- und Raumfahrt, September 2014.
[40] L. Batista and O. Hammami, “Capella based system engineering mod-
elling and multi-objective optimization of avionics systems,” in 2016
IEEE Intl. Symposium on Systems Engineering, Oct 2016, pp. 1–8.
[41] J. Yin, B. Lawler, and H. Jin, “Application of model based system
engineering to IMA development activities,” in 2017 IEEE/AIAA 36th
Digital Avionics Systems Conference, Sept 2017, pp. 1–7.
[42] M. Halle and F. Thielecke, “Model-based transition of IMA architecture
into configuration data,” in 35th Digital Avionics System Conference,
Sacramento,CA , USA, September 2016.
[43] T. Belschner et al., “Automated generation of certification relevant
documentation for a distributed avionics platform approach,” in 2016
IEEE/AIAA 35th Digital Avionics Systems Conference, Sept 2016, pp.
1–10.
[44] Dalldorff, Luckner, and Reichel, “Full-authority automatic flight control
system for the civil airborne utility platform S15 - LAPAZ,” in IEEE
2nd CEAS Specialist Conference on Guidance, Navigation & Control,
2013.
[45] Dries, W. Fichter, A. Joos, Mayerbuch, Müller, Pinchetti, R. Reichel,
R.-R. Riebeling, Stephan, and Volck, “Automatischer start und land-
ing einer diamond DA42,” in Deutscher Luft- und Raumfahrtkongress
(DGLR), 2016.
[46] B. Annighöfer, H. Höber, and F. Thielecke, “An easy-to-use real-
time AFDX simulation framework,” in 35th Digital Avionics System
Conference, Sacramento, CA , USA, 9 2016.
[47] M. Halle and F. Thielecke, “Tool chain for avionics design, development,
integration and test,” in 1st Workshop on Avionics Systems and Software
Engineering, 2019.
[48] A. Davis, Software requirements: objects, functions, and states.
Prentice-Hall, Inc. Upper Saddle River, NJ, USA, 1993.
[49] W. Schamai et al., “Virtual verification of system designs against
system requirements,” in Models in Software Engineering, J. Dingel and
A. Solberg, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011,
pp. 75–89.
[50] A. Pop, D. Akhvlediani, and P. Fritzson, “Towards unified system
modeling with the ModelicaML UML profile,” Simulation News Europe,
vol. 17, no. 2, pp. 9–15, Sep. 2007.
[51] M. Tiller, Introduction to Physical Modeling with Modelica, ser. The
Springer Intl. Series in Engineering and Computer Science. Kluwer
Academic Publishers, 2001.
[52] M. Broy and K. Stølen, Specification and Development of Interactive
Systems. Springer, 2001.
[53] I. H. Krueger, W. Prenninger, and R. Sandner, “Broadcast mscs,” Formal
Aspects of Computing, vol. 16, no. 3, pp. 194–209, 2004.
[54] I. H. Krueger, “Distributed system design with message sequence
charts,” Ph.D. dissertation, 2000.
[55] F. Hölzl and M. Feilkas, “Autofocus 3: A scientific tool prototype
for model-based development of component-based, reactive, distributed
systems,” in Proc. of the 2007 Intl. Dagstuhl Conference on Model-
based Engineering of Embedded Real-time Systems, ser. MBEERTS’07.
Berlin, Heidelberg: Springer-Verlag, 2010, pp. 317–322.
[56] S. Kriebel, D. Raco, B. Rumpe, and S. Stueber, “Model-based engineer-
ing for avionics: Will specification and formal verification e.g. based on
broy’s streams become feasible?” in 1st Workshop on Avionics Systems
and Software Engineering, 2019.
[57] K. Hoelldobler and B. Rumpe, MontiCore 5 Language Workbench
Edition 2017. Shaker Verlag, 2017, vol. 32.
[58] T. Nipkow, L. C. Paulson, and M. Wenzel, Isabelle/HOL — A Proof
Assistant for Higher-Order Logic, ser. LNCS. Springer, 2002, vol.
2283.
[59] P. M. Duvall, S. Matyas, and A. Glover, Continuous Integration, ser.
Addison-Wesley Signature Books. Addison-Wesley, 2007.
[60] J. Humble and D. Farley, Continuous Delivery, ser. Addison-Wesley
Signature Series. Addison-Wesley, 2010.
[61] M. Daum, J. Dörrenbächer, and B. Wolff, “Proving fairness and imple-
mentation correctness of a microkernel scheduler,” Journal of Automated
Reasoning, vol. 42, no. 2, pp. 349–388, Apr 2009.
[62] O. Kunčar, “Correctness of isabelle’s cyclicity checker: Implementability
of overloading in proof assistants,” in Proceedings of the 2015 Confer-
ence on Certified Programs and Proofs, ser. CPP ’15. New York, NY,
USA: ACM, 2015, pp. 85–94.
[63] C. A. R. Hoare, “An axiomatic basis for computer programming,”
Communications of the ACM, vol. 12, pp. 576–580, 1969.
[64] F. Kirchner et al., “Frama-c, a software analysis perspective,” In Formal
Aspects of Computing, vol. 27, no. 3, 2015.
[65] J. W. McCormick and P. C. Chapin, Building High Integrity Applications
with SPARK. Cambridge University Press, 2015.
[66] Y. Moy, E. Ledinot, H. Delseny, V. Wiels, and B. Monate, “Testing
or formal verification: Do-178c alternatives and industrial experience,”
IEEE Software, vol. 30, no. 3, pp. 50–57, May 2013.
[67] C. Baier and J.-P. Katoen, Principles of Model Checking. The MIT
Press, 2008.
[68] J. Esparza and K. Heljanko, Unfoldings, ser. Monographs in Theoretical
Computer Science. An EATCS Series. Springer, 2010.
[69] K. L. McMillan, “Using unfoldings to avoid the state explosion problem
in the verification of asynchronous circuits,” ser. Lecture Notes in
Computer Science, G. von Bochmann David K. Probst, Ed., vol. 663.
Springer, 1992, pp. 164–177.
[70] ——, Symbolic Model Checking. Kluwer Academic Publishers, 1993.
[71] ——, “A technique of state space search based on unfolding,” Formal
Methods in System Design, vol. 6, no. 1, pp. 45–65, 1995.
[72] C. Schroeter and V. Khomenko, “Parallel LTL-X model checking of
highlevel petri nets based on unfoldings,” ser. Lecture Notes in Computer
Science, R. Alur and D. Peled, Eds., vol. 3114. Springer, 2004, pp.
109–121.
[73] S. H. VanderLeest et al., “A framework for analyzing shared resource
interference in a multicore system,” in 2018 IEEE/AIAA 37th Digital
Avionics Systems Conference, Sept 2018.
Authorized licensed use limited to: University of Waterloo. Downloaded on May 30,2020 at 00:24:25 UTC from IEEE Xplore. Restrictions apply.
[74] R. Wilhelm et al., “Designing predictable multicore architectures for
avionics and automotive systems,” in Workshop on Reconciling Perfor-
mance with Predictability, Oct 2009.
[75] U. Dersch, “PLUS avionics whitepaper,” plc-tec, Whitepaper, 09 2018.
[76] Real-Time Innovations (RTI), “Rti releases first do-178c certification
data package for its safety-critical connectivity platform,” 2015.
[77] S. H. VanderLeest, “Designing a future airborne capability environment
(face) hypervisor for safety and security,” in 2017 IEEE/AIAA 36th
Digital Avionics Systems Conference, Sept 2017.
[78] S. Toumassian et al., “Performance measurements for hypervisors on
embedded arm processors,” in Intl. Conference on Advances in Com-
puting, Communications and Informatics, Sept. 21-24 2016.
[79] M. Narang et al., “Uav-assisted edge infrastructure for challenged net-
works,” in IEEE Conference on Computer Communications Workshop,
May 2017, pp. 60–65.
[80] C. Watkins, C. Nilson, S. Taylor, K. Medin, I. Kuljanin, and H. Nguyen,
“Development of touchscreen displays for the Gulfstream G500 and
G600 Symmetry(TM) flight deck,” in 2018 IEEE/AIAA 37th Digital
Avionics Systems Conference, London, UK, Sept 2018.
[81] L. Ryon and G. Rice, “A safety-focused security risk assessment of
commercial aircraft avionics,” in 2018 IEEE/AIAA 37th Digital Avionics
Systems Conference, Sep. 2018, pp. 1–8.
[82] H. Teso, “Aircraft hacking – practical aero series,” Apr. 2013, hITBSEC
Conference 2013 Amsterdam.
[83] P. Berthier, C. Bresteau, and J. Fernandez, “On the security of aircraft
communication networks,” in Critical Information Infrastructures Secu-
rity, G. D’Agostino and A. Scala, Eds. Cham: Springer Intl. Publishing,
2018, pp. 266–269.
[84] J. Juerjens, Secure Systems Development with UML, 1st ed. Springer,
2005.
[85] S. Crane, A. Homescu, S. Brunthaler, P. Larsen, and M. Franz, “Thwart-
ing cache side-channel attacks through dynamic software diversity,”
in 22nd Annual Network and Distributed System Security Symposium,
2015, San Diego, California, USA, February 8-11, 2015, 2015.
[86] A. Burgess, The Executive Guide to Artificial Intelligence, 1st ed.
Palgrave Macmillan, 2018.
[87] I. Aizenberg, N. N. Aizenberg, and J. P. Vandewalle, Multi-Valued
and Universal Binary Neurons: Theory, Learning and Applications.
Springer Science and Business Media, 2013.
[88] D. Silver et al., “Mastering the game of go without human knowledge,”
Nature, no. 550, pp. 354–359, 2017.
[89] C.-H. Cheng et al., “Neural networks for safety-critical applications —
challenges, experiments and perspectives,” in 2018 Design, Automation
Test in Europe Conference Exhibition, March 2018, pp. 1005–1006.
[90] C.-H. Cheng, G. Nuehrenberg, and H. Ruess, “Maximum resilience of
artificial neural networks,” in Automated Technology for Verification and
Analysis, 15rd Intl. Symposium, D. D’Souza and K. N. Kumar, Eds.
Pune, India: Springer Intl. Publishing, 2017, pp. 251–268.
[91] C.-H. Cheng, G. Nuehrenberg, H. Ruess, and H. Yasuoka, “Towards
dependability metrics for neural networks,” in Proc. of the 16th ACM-
IEEE Intl. Conference on Formal Methods and Models for System
Design (MEMOCODE’18), 2018.
[92] A. Kurakin, I. J. Goodfellow, and S. Bengio, “Adversarial examples in
the physical world,” in Intl. Conference on Learning Representations
Workshop Track, 2017.
[93] K.-P. L. Vu, J. Lachter, V. Battiste, and T. Z. Strybel, “Single pilot
operations in domestic commercial aviation,” Human Factors, vol. 60,
no. 6, pp. 755–762, 2018, pMID: 30063410.
[94] S. M. Neis, U. Klingauf, and J. Schiefele, “Classification and review
of conceptual frameworks for commercial single pilot operations,” in
2018 IEEE/AIAA 37th Digital Avionics Systems Conference (DASC),
Sep. 2018, pp. 1–8.
[95] Y. Lim, V. Bassien-Capsa, S. Ramasamy, J. Liu, and R. Sabatini, “Com-
mercial airline single-pilot operations: System design and pathways
to certification,” IEEE Aerospace and Electronic Systems Magazine,
vol. 32, no. 7, pp. 4–21, July 2017.
[96] G. A. Boy, “Requirements for single pilot operations in commercial
aviation: A first high-level cognitive function analysis,” in Proc. of the
Poster Workshop at the 2014 Complex Systems Design, 2014.