Avionics Technology 47

Table 2.2 RTCA-DO-178 design quality assurance levels

Design
assurance level Criteria

A Design whose anomalous behaviour as shown by the system safety assessment

would cause or contribute to a failure of system function resulting in a
catastrophic failure condition for the aircraft
B Design whose anomalous behaviour as shown by the system safety assessment
would cause or contribute to a failure of system function resulting in a
hazardous failure condition for the aircraft
C Design whose anomalous behaviour as shown by the system safety assessment
would cause or contribute to a failure of system function resulting in a major
failure condition for the aircraft
D Design whose anomalous behaviour as shown by the system safety assessment
would cause or contribute to a failure of system function resulting in a minor
failure condition for the aircraft
E Design whose anomalous behaviour as shown by the system safety assessment
would cause or contribute to a failure of system function resulting in a no
effect failure condition for the aircraft

• Verification: Evaluate the results of a process for correctness and consistency to ensure that
they are functionally correct and that they properly translate the choices and hypotheses
made. Verification is not simply testing; it is typically a combination of reviews, analyses
and tests.

2.7.5 Languages
Ada has been the preferred language of choice for embedded systems. Ada is a powerful and
versatile language that includes provision for floating point arithmetic. It has been widely
used; its benefits include:

• code portability and reusability;

• increased productivity;
• increased reliability (fewer coding errors);
• increased maintainability;
• good exception handling capabilities;
• supports parallel and concurrent processing;
• supports object-oriented design.

Spark Ada is a subset of Ada with particular properties that make it ideally suited to safety-
critical applications. It is completely unambiguous and free from implementation depen-
dencies. All rule violations are detectable. It was mandated for US Department of Defense
programmes, but is no longer enforced due to lack of qualified programmers.
C++ is the most popular realistic alternative to Ada today. Some C++ features, if not
properly controlled and verified, can lead to software code that is non-deterministic, unused,
48 Civil Avionics Systems

Check Software Derive

Tests
Consistency Requirement Tests

Check Validate
Consistency Specification Specification

Check Software Derive

Consistency Specification Tests

Check Tests
Design
Consistency

Check Software Derive

Consistency Design Tests

Check Tests
Coding
Consistency

Check Derive
Code
Consistency Tests

Tests

Conduct Tests

Software Test
System Results

Figure 2.32 Software development life-cycle

difficult to verify, and whose configuration can change depending on the run-time state of
the system. The Certification Authorities Software Team (CAST) published guidance in 2002
that identified common problems with C++ for DO-178 safety-critical applications. Many
organisations have defined ad hoc C++ subsets to achieve DO-178 compliance. The Motor
Industry Reliability Association (MISRA) specifies a ‘safe’ subset which defines 228 rules.
Programming Research Inc. offer a qualified static code analyser tool (QA C++) which
verifies source code conformance and is able to identify unsafe usage of C++.
Avionics Technology 49

2.7.6 Object-Oriented Design

RTCA-DO-178C has been five years in development through RTCA and EUROCAE. It was
completed in November 2011 and approved/released in January 2012. The enhanced standard
allows credit for modern software design technologies including:

• object-oriented programming (OOP) languages;

• formal methods;
• model-based development methods.

The hitherto ‘classic’ approach to software design gives priority to functions rather than data.
Experience shows that the data handled by the software are more stable than the processes
involved with it. Object-oriented design therefore gives priority to the data. The ‘problem’
to be designed is tackled by modelling a collection of objects, each of which implements a
specific task. The possible states and behaviour of an object are defined by ‘classes’. Each
object constitutes an instance of a class. The ‘solution’ to the problem is provided by the
interaction of the objects.
Object-oriented methods have been used for software as different from each other as mission-
critical systems to commercial data processing systems. There are object-oriented methods
for software requirements analysis, software design and programming. Major milestones in
the development of object-oriented design and analysis techniques have been:

• object-oriented analysis (OOA) – Coad & Yourden and others (1991)

• object-oriented design and analysis (OOA & OOD) – Grady Booch and others (1997 &
1994)
• hierarchical object-oriented design (HOOD)
• object modelling technique (OMT) (1991)
• Unified Modelling Language (UML)

OOA and OOD model a system as a group of interacting objects communicating by messages,
where each object is responsible for the accomplishment of tasks according to its state. Each
object represents an entity of interest, characterised by its class, its state (data elements) and its
behaviour. Models can be created to show the static structure, dynamic behaviour and run-time
deployment of these collaborating objects.

• Object-oriented analysis (OOA) focuses on what the system does.

• Object-oriented design (OOD) focuses on how the system does it.

Object modelling technique (OMT) applies to all the software development processes, from
analysis to implementation. It uses three different views to capture important aspects of the
software:

• Object model: Represents the static aspects of the software (classes, relationships, etc.) and
provides a framework into which the dynamic and functional models will be placed.
• Dynamic model: State transition diagrams describe the temporal aspects, the sequences of
operations and events that produce changes in state within a class.
50 Civil Avionics Systems

• Functional model: Data flow diagrams show interdependencies of input and output
processes.

OMT provides a very complete static model. It uses the same graphic notation throughout the
analysis and design phases and provides a powerful description of the internal behaviour of
the objects
Unified Modelling Language (UML) embraces the earlier notations of object-oriented anal-
ysis (OOA) and design (OOD), the Booch method and the object modelling technique (OMT),
and fuses them into a single, common, widely used modelling language. UML offers a standard
way to visualise a system’s architectural blueprints, including elements such as:

• actors;
• processes;
• (logical) components;
• activities;
• programming language statements;
• database schemas;
• reusable software components.

UML aims to be a standard modelling language which can model concurrent and distributed
systems. It is a de facto industry standard, and is evolving under the auspices of the Object
Management Group (OMG).

2.7.7 Auto-code Generation

There is a progressive move away from developing code from the OOA/UML formal model
to automatically generating code from it:

• The advantages are:

– reduced cost of development
– faster timescale
– easier to change.
• The potential issues to address are:
– ability to certify safety-critical real-time systems
– availability of qualified tools
– bloated code
– intelligibility (is it readable?).

Model-based tools model systems in very high-level, domain-specific languages. They

can be used to automatically generate source code directly from the model. Both the model
and the code have to be verified to DO-178. DO-178C provides objective criteria to prove
that automated verification tools have been properly qualified and can be trusted. The ‘Tools
Supplement’ explains what a tool provider has to do in order to qualify the tools. Some popular
auto-code tools are:
Avionics Technology 51

SCADE
SCADE is a development environment used by system and software engineers to produce
mission- and safety-critical applications. It is based upon the formal, synchronous and data-
flow-oriented Lustre programming language, and generates production-quality C or Ada code.
It is a qualified development tool for DO-178 applications up to level A and has been used in
aerospace and defence applications, for example:
• flight control systems (e.g. A340 and A380);
• power management;
• reconfiguration management;
• autopilots;
• engine control systems (FADEC);
• braking systems;
• cockpit display and alarm management (e.g. NH90);
• fuel management.

SimulinkC
SimulinkC , developed by MathWorks, is a commercial tool for modelling, simulating
and analysing multidomain dynamic systems. Its primary interface is a graphical block
diagramming tool and a customisable set of block libraries. It offers tight integration with the
MATLABC environment and can either drive MATLABC or be scripted from it. SimulinkC
is widely used in control theory and digital signal processing for multidomain simulation
and design.
A number of MathWorks and third-party hardware and software products are available for
use with SimulinkC . Stateflow extends SimulinkC with a design environment for developing
state machines and flow charts. Real-Time Workshop extends SimulinkC to generate C source
code automatically for real-time implementation of systems.

VAPS
VAPS DO-178 qualified code generator from Presagis is applicable to all types of embedded
display graphics ranging from digital and analogue instrumentation to menu-based displays. It
offers control and flexibility in the design of dynamic, interactive, real-time human–machine
interfaces (HMIs). It allows users to define both the visual appearance of a display object and
the logic (state machine) that controls it in one graphical editor. Developers and human factors
experts can define the look and feel of an object or group of objects, assign behaviour, and
subsequently generate executable source code.

2.7.8 Real-Time Operating System (RTOS)

As discussed earlier in this chapter, avionics computations must be executed in ‘real-time’
on a repetitive cyclic basis. The Nyquist criteria must be obeyed. Consequences of missed
deadlines are:
• control loop instability;
• data latency;
52 Civil Avionics Systems

• poor frequency response;

• aliasing;
• jitter;
• missed events;
• false warnings/error messages;
• other relevant design considerations.

The application software is run on the target machine under the control of a real-time operating
system (RTOS) which:

• manages task state;

• selects the task execution sequence;
• creates and destroys tasks;
• changes task priority;
• provides recovery from stuck tasks;
• manages interrupts;
• manages synchronous and asynchronous tasks;
• manages memory;
• provides memory protection and memory allocation;
• provides inter-process communication.

The operating system for integrated modular avionics systems must provide additional
features in order to support the IMA objectives discussed in Chapter 5, and in particular
Section 5.7. ARINC 653 specifies the requirements for an IMA RTOS. The operating system:

• Provides a partitioned environment. Periodic fixed scheduling bounds computing resource

demands. Hardware memory management protects RAM/ROM utilisation. I/O resource
allocation bounded in hardware configuration tables. Partitioning facilitates incremental
certification.
• Supports multiple, isolated applications and guarantees that application failure effects are
limited to the partition.
• Permits multitasking within a partition.
• Permits applications with different certification standards to run on same hardware platform.
• Supports application code portability and interchangeability.

ARINC 653 defines an Application Executive (APEX) and an Application Programming

Interface (API) which decouples application software from the target platform. Each appli-
cation software item is assigned a partition with its own memory space and dedicated time
slot allocated to it by the APEX API. The APEX API provides services to manage partitions,
processes and timing, as well as partition/process communication and error handling. The
ARINC 653 APEX services and API calls are categorised as:

• partition management;
• process management;
• time management;
Avionics Technology 53

• inter-partition communication;
• intra-partition communication;
• error handling.

2.8 Microprocessors
A microprocessor is a semiconductor device that incorporates most or all of the features
of a central processing unit (CPU) on a single integrated circuit (also known as a chip).
Microprocessors emerged in the early 1970s and were first used in electronic calculators,
point-of-sale till machines and cash dispensers. Affordable 8-bit microprocessors capable
of performing control-type embedded applications appeared in the mid-1970s and spawned
the personal computer (PC) industry. No longer were computers the sole domain of large
corporations and government organisations. Today 32- and 64-bit multicore machines running
at clock rates exceeding 1 GHz are readily available and affordable for desktop applications
with processing power that far exceeds the imagination of computer systems designers in the
1970s. Then, similar processing power required a large room full of power-hungry computers,
requiring a handful of computer scientists to operate and maintain them.

2.8.1 Moore’s Law

In 1965, Gordon Moore, a co-founder of Intel, predicted the future of microprocessor-based
computing in his now-famous Moore’s Law: “Microprocessor processing power will double
every two years”. As illustrated in Figure 2.33, his prediction has largely proven to be correct.

Transistors
per Chip

Xeon
1 billion
i7
Pentium IV
100 million
Pentium III
Pentium II 10 million
Pentium
‘486 1 million
‘386 Moore’s Law
‘286
100 thousand
8086
8080 10 thousand
8008
4004
1 thousand
1970 1980 1990 2000 2010

Figure 2.33 Moore’s Law

54 Civil Avionics Systems

2.8.2 Significant Microprocessors used in Aerospace Applications

Intel 4004
Released in 1971, the Intel 4004 was the first commercially available CPU on a single integrated
circuit (IC) chip. It had a simple architecture (see Figure 2.34) with the following features:

• a 4-bit machine, with a 4-bit ALU and 8-bit instructions;

• a 12-bit memory address field accessing a maximum memory capacity of 4096 bytes of
memory via a multiplexed 4-bit bus;
• a clock frequency of 740 kHz, and an instruction execution time of 10.8 μs;
• 46 instructions, and 16 registers;
• 2300 transistors, 10 μm process in a 16-pin dual in-line package (DIP).

Intel 8086
Released in 1978, this was the first 16-bit microprocessor. An earlier 8-bit version, the Intel
8080, was the basis for the first IBM PC. Intel later released a maths co-processor (Intel
8087) which supported floating point arithmetic. A simplified version of the architecture and
instruction set are used in the CPU execution example in Section 2.6. It had the following
features:

• 16-bit data and instructions, 20-bit address (paged);

• a clock frequency of 10 MHz and a 2 μs instruction execution time (average);
• dual ALU (data and address), 8 registers, limited pre-fetch queue (cache);
• 20,000 transistors, 3.2 μm process in a 40-pin surface mount package.

The Intel 8086 was probably the first microprocessor to be widely used in avionics appli-
cations by several companies in the mid-1980s for embedded federated architecture avionics
computers in both civil and military applications (e.g. flight management computers, display
symbol generators, mission computers, autopilots, fuel gauging and management comput-
ers, etc.).

Motorola M68020
Released in 1984, the Motorola M68020 was a 32-bit processor first used in the Apple Mac
II personal computer, SUN workstations and many industrial and aerospace applications.
It was selected by the Eurofighter Typhoon project to be the processor of choice for all
the avionics systems computers. It was also used in the French TGV. It had the following
features:

• 32-bit data/instructions, and 32-bit memory address;

• a clock frequency of 33 MHz, and throughput of 10 million instructions per second (MIPS);
• 256 byte instruction cache;
• 114-pin ceramic pin-grid array package.
 4 Bit Bi-Directional
Data Bus

Data Bus
Buffer
4 Bit Internal Bus

Temp
Accumulator Instruction Register
Register
Register Multiplexer
0 1
Stack
Multiplexer 2 3
Flags
Program Counter 4 5
Instruction
Decoder and Level No 1
Execution 6 7
Unit Level No 2
8 9
Stack Pointer

Level No 3
10 11
Index Register Select

Address Stack
12 13
Decimal
Adjust 14 15

Scratch Pad

Timing and Control

Figure 2.34 Intel 4004 microprocessor

56 Civil Avionics Systems

Most significantly, the M68020 provided extensive memory management functions to protect
and segregate areas of memory to facilitate robust partitioning.

Intel Pentium
Probably the most universally known microprocessor family used in desktop computing, the
Intel Pentium D was released in 2008 as a dual-core, 64-bit, x86 microprocessor on the
multichip module. It has the following features:

• 64-bit data/instructions, 32-bit memory address;

• a clock frequency of 3.73 GHz with a front-side bus 533 to 1066 MHz (different variants);
• x86-64 instruction set;
• 1 Mb L2 cache and 256 byte instruction cache;
• 65 nm process, dissipating 130 W in a 700-pin grid array package.

PowerPC
Performance Optimization With Enhanced RISC – Performance Computing (PowerPC), is
a reduced instruction set computing (RISC) architecture created by the 1991 Apple–IBM–
Motorola alliance, known as AIM. RISC allows scalable designs for low-end (8-bit) applica-
tions to high-end (64-bit and above) applications. The small size of the CPU core allows a
great deal of room on each die for additional components, such as instruction and data cache
or maths co-processors.
Originally intended for personal computers, PowerPC CPUs have since become popular as
embedded and high-performance processors. PowerPC was the cornerstone of AIM’s Common
Hardware Reference Platform initiatives in the 1990s, and while the POWER1 architecture is
well known for being used by Apple’s Macintosh products from 1994 to 2006 (before Apple’s
transition to Intel), its use in video game consoles and embedded applications provided an
array of uses. Most importantly, the suppliers of PowerPC components are prepared to support
industrial applications by providing industrial and aerospace grade components with specified
performance over a wider operating temperature range and a more severe environment than
the Pentium.
In 2004, Motorola exited the chip manufacturing business by spinning off its semiconductor
business as an independent company called Freescale Semiconductor. IBM exited the 32-bit
embedded processor market by selling its line of PowerPC products to Applied Micro Circuits
Corporation (AMCC) and focused on 64-bit chip designs. The IBM–Freescale alliance was
replaced by an open standards body called Power.org. IBM continues to develop PowerPC
microprocessor cores for use in their server products for large businesses, and continues to
evolve POWER processors which implement the full PowerPC instruction set architecture.
Freescale Semiconductor continues to evolve products for embedded systems.
The evolution and some key examples of the PowerPC range are shown below.

• POWER1 (1991) introduced in Apple-Mac machines, outperforming Intel x86.

• POWER3 (‘603 and ‘604) full 64-bit implementation, including low cost/low power
versions.