Avionics Technology 37

Flow chart:
Compute value y from x
according to the relationship:
Set Accumulator (A) to x Acc:=x

Multiply Accumulator by m Acc:=mx

y Slope = m
Add c to Accumulator Acc:=mx+c

k Yes
Is Accumulator
y = mx + c <= k
c No
If Acc > k
Set Accumulator to k
Then Acc:=k
x

y:=mx+c
Store Accumulator in y
limited at k

Figure 2.24 Flow chart to evaluate y = mx + c

Evaluation of the algorithm commences with the instruction register set to 100.

• Fetch instruction: ALU(A) is set to the function R = A + 0 and its output is routed through
the memory interface to address the memory at location 100 and the instruction ‘Load the
Accumulator with the contents of memory location 300’ is fetched from memory (memory
read cycle). The operand address, in this case 300, now appears on the B port of ALU(A).
• Fetch data: ALU(A) is now set to the function R = 0 + B and addresses the memory at
location 300. Variable x is fetched from memory (since memory location 300 contains the
value of variable x) and this now appears on the B port of ALU(D).
• Execute instruction: ALU(D) is now commanded to execute the ‘Load’ instruction and is
set to the function R = 0 + B, and variable x is loaded into the accumulator register.

This completes the first instruction and the CPU steps onto the next instruction by incrementing
the instruction register to the value 101, and the execution cycle commences again:

• Fetch instruction: Fetches the instruction at memory location 101, namely ‘Multiply the
Accumulator with the contents of memory location 200’. The operand address, in this case
200, now appears on the B port of ALU(A).
• Fetch data: Constant m at memory location 200 is fetched from memory and this now
appears on the B port of ALU(D).
• Execute instruction: ALU(D) is now commanded to execute the ‘Multiply’ function R =
A × B by a series of add and shift operations into the Accumulator register, resulting in it
taking the value of x multiplied by m.
 R A
Addr Op Reg Op Addr Result 3. Read Memory
2. ALU(A) Set to
at location 100
R= A+0 = 100 R=A+0 100 Load
L Acc 300 Acc:= x
Address
A B 100 101 Multiply Acc 200 Acc:= mx
Fetch
Instruction 102 Add Acc 201 Acc:= mx + c
Read/
100 Write
Instruction 103 Skip if < = Acc 202 If Acc >k then Acc := k
IInstruction Execution Unit

Memory
Register 104 Load Acc 202

M Interface
300 105 Store Acc 301 y := Acc

D
Data 106 Loop back 6
1. Instruction
Register = 100 --------
200 Constant m

201 Constant c
Accumulator
A (A) 4. Operand 202 Constant k
Address = 300
--------
300 Variable x

A B 301 Variable y

ALU (D)
A
Memory
R

Central Processing Unit

Figure 2.25 Fetch instruction

 R Addr Op Reg Op Addr Result
1. ALU(A) Set to 100 Load Acc 300 Acc := x
R=A+0
R=0+B = 300 Address
A B 300 101 Multiply Acc 200 Acc := mx
Fetch Data
102 Add Acc 201 Acc := mx + c
Read/
100 Write 103 Skip if <= Acc 202 If Acc >k then Acc := k
Instruction
Fetch
Instruction Execution Unit

Memory
Interface
Register 100 Instruction 104 Load Acc 202

Var x 105 Store Acc 301 y := Acc

300
Data 106 Loop back 6

--------
200 Constant m

201 Constant c
Accumulator (A)
3. Operand = x 202 Constant k

--------
2. Read Memory
300 Variable x
at location 300
A B 301 Variable y

ALU (D)
Memory
R

Central
C entral Processing
Processing Unit
Unit

Figure 2.26 Fetch data

 R Addr Op Reg Op Addr Result

R=A+0 100 Load Acc 300 Acc := x

Address
A B 101 Multiply Acc 200 Acc := mx
Execute
Instruction 102 Add Acc 201 Acc := mx + c
Read/
Write 103 Skip if <= Acc 202 If Acc >k then Acc := k
Instruction
Fetch
Instruction Execution Unit
Register 100 Instruction 104 Load Acc 202

Memory Interface
Load Acc 105 Store Acc 301 y := Acc
cc

Data 106 Loop back 6

--------
200 Constant m

2. Load Var x 201 Constant c

Accumulator
Accumulator (A) Var x 202 Constant k

--------
300 Variable x

Var x A B 301 Variable y

ALU (D)
Memory
1. ALU(D) Set to R
R=0+B
Central Processing Unit

Figure 2.27 Execute instruction

Avionics Technology 41

The CPU steps onto the next instruction at memory location 102, and the execution cycle
repeats again, this time:

• Fetch instruction: ‘Add to the accumulator the contents of memory location 201’.
• Fetch data: Constant c is fetched from memory.
• Execute instruction: ALU(D) is now commanded to execute the ‘Add’ function R = A +
B and writes the answer back into the accumulator register resulting in it taking the value
of mx + c.

The CPU steps onto the next instruction at memory location 103, and the execution cycle
repeats again, this time:

• Fetch instruction: ‘Skip if the accumulator contents are less the value of memory location
202’.
• Fetch data: Constant k is fetched from memory.
• Execute instruction: ALU(D) is now commanded to execute the ‘subtract’ function R =
A − B, but this time it does not write the contents back into the accumulator register; instead
the instruction register is incremented if the answer is negative, that is, mx + c is less than
constant k, then the next instruction is skipped.

The CPU steps onto the next instruction. The instruction at memory location 104 will only be
executed if mx + c is greater than constant k. This instruction is a ‘Load’ instruction like the
first at location 103, and will overwrite the accumulator register with the constant k.
The instruction at memory location 105 is a little different to previous instructions.

• Fetch instruction: ‘Write the accumulator contents to memory location 301’.

• Store data: ALU(A) is set to the function R = 0 + B through the memory interface to
address the memory at location 301 as before. ALU(D) is now commanded to execute the
function R = A + 0, but this time it does not write the contents back into the accumulator
register; instead its output is routed to the memory interface and written to memory location
301 (memory write cycle).

The final instruction at memory location 106 changes the instruction sequence:

• Fetch instruction: ‘Loop back by 6’.

• Load instruction register: ALU(A) is set to the function R = A − B, but this time it does
not address the memory; instead its output is loaded back into the instruction register which
loops the instruction sequence back to begin again at memory address 100.

The above rather simple example serves to illustrate how a CPU fetches and executes
instructions contained in its memory and reads and writes data to and from memory. It can be
seen that the memory contains three classes of information:

• instructions;
• constants;
• variables.
42 Civil Avionics Systems

The memory characteristics required for these classes differs; the implications are explored
further in Section 2.9.

2.6.3 Extended Operand Addressing Modes

In general the computer memory is much larger than can be addressed by the simple mecha-
nisms illustrated above, and a range of techniques (or modes) together with a set of registers,
usually called the index registers, are used to extend the address range. The index registers
are a set of address registers whose contents can be loaded and manipulated arithmetically
by ALU(A) to provide various means to index or point to areas of memory. The architecture
arrangement is shown in Figure 2.28.
Some of the address modes include:

• Direct addressing: This is used to access data (generally constants) in the same segment
(page) as the instructions being executed. The resultant operand address is the current
instruction page concatenated (joined) with the short operand address in the instruction.
• Relative addressing: This is used to access data (generally constants) in the same block of
code as the instructions. The resultant operand address is the current instruction address plus
the short operand address in the instruction. This mode has the benefit that the instruction
code block with associated constants can be relocated in memory without revising the short
operand addresses, since each address is relative to the instruction that called it.
• Indexed addressing: This is used to access data (generally variables), data tables, first-in
first-out stacks and data arrays. The resultant operand address is the selected index register
plus the short operand address in the instruction.

Extended Op Address

ALU

Index Registers Instruction Register

Page Line/Row

Op Code Reg Mode Op Address

Figure 2.28 Operand (data) address modes

Avionics Technology 43

2.7 Software
2.7.1 Software Introduction
Software is the heart of modern digital avionics. It gives the system a flexibility that is far
beyond that achievable from analogue equivalents. The software describes algorithms, logical
statements, data and control processes. Designing, coding and testing software requires unique
procedures to prove beyond reasonable doubt that the software is at least as reliable as its host
hardware. Separate, but similar procedures have been developed for military and civil avionics
systems, but with the same broad intent.
Investment in software is vast. The Airbus A320 avionics system has around 800,000 lines of
code. The Boeing 777 avionics system has in excess of 4,000,000 lines of code running on 50-
plus hardware platforms. The Airbus A380 and Boeing 787 will have many more lines of code.
As a rough order of magnitude it has been said that the number of lines of code for an avionics
system doubles every 10 years, with a commensurate increase in the man-hours/man-days
required to develop and certify the software to the appropriate design assurance level (DAL).
This section is intended only as an introduction to the subject. For further information the
reader is directed to other works on the subject [6].

2.7.2 Assemblers and Compilers

The software code developed in Section 2.6 is known as assembler level code. It is a set of
pseudo-English language statements that have a 1:1 correspondence with the machine exe-
cutable binary code that the CPU understands. Translation from the pseudo-English language
assembler code to machine code is performed by a machine-specific translator known as an
assembler. A linker/loader assigns specific memory addresses at the final stages of generating
the machine code executable binary, to load and run the code from a specific area of memory.
Software is seldom written at assembler level. It would be totally impractical to code an
avionics system this way. Possibly the only exception is device driver software which needs
to specifically control and pass data between hardware components at register level. The
application software will be written in a high-order language such as Ada or C++ which is
not machine-specific and does not require the programmer to have intimate knowledge of the
target machine architecture or its instruction set.
Good programming technique devolves the application software into a hierarchical structure
of tasks, processes and objects that are then executed under the control of a real-time oper-
ating system (RTOS), which manages all the computing resources in accordance with agreed
resource allocations (also known as the run-time environment). High-order source code in lan-
guages such as Ada and C++ is translated to run on the target machine by a compiler where
it is combined with lower-level device drivers as necessary to produce machine loadable and
executable target code. The process is illustrated in Figure 2.29.

• The compiler: Translates the application software (source code) into an intermediate form.
It performs syntax checking, (mis)use of types and generates warnings or errors.
• The assembler: Translates the intermediate code to machine code (object code), which is
the sequence of binary numeric values representing CPU-specific instructions plus data and
references to data.
44 Civil Avionics Systems

Application
(High -order language
Non -machine specific
e.g. Ada, C++
All designed and built to
appropriate levels of
assurance to meet
Compiler
integrity requirements.
Source Code
(Low -order language
Machine -specific
Using Computer Aided
Assembler) Software Engineering
(CASE) tools.

Assembler

Scheduler/
Object Code Object Code (e.g. I/O Drivers
Run -Time Executive/
Real -Time Operating System
Linker/Loader

To Program
Machine Code (executable binary)
Memory (ROM)

Figure 2.29 Assemblers, compilers and operating systems

• The linker: Combines multiple machine code entities into a single executable entity and
resolves address references between entities.
• The loader: Writes the run-time executable code into the assigned CPU memory locations.
• Firmware: The Institute of Electrical and Electronics Engineers (IEEE) Standard Glossary
of Software Engineering Terminology, Std 610.12-1990, defines firmware as “The combi-
nation of a hardware device and computer instructions and data that reside as read-only
software on that device,” and adds that the confusion surrounding this term has led some to
suggest that it be avoided altogether.

2.7.3 Software Engineering

The development of software may turn out to be very complex. The development of most
avionics applications requires teamwork. The complexity arises from the following elements:

• The size of the problem (system) domain to be dealt with.

• The difficulty in managing the development process.
• The flexibility constraints required for the final software.
• The problems caused by the compilation and analysis of the system being designed.

The aims of software engineering are to develop software which is:

• Modifiable: In order to modify software effectively it is necessary to assimilate all the

design decisions. If not done, then the modifications are only rough indiscriminate repairs.
Modifiable software must allow changes without increasing overall complexity.
Avionics Technology 45

• Effective: Uses the available resources to the best advantage. The limited resources are time
(available calculation power) and space (available memory and available I/O).
• Reliable: Eliminating design faults and taking recovery action if dysfunctions occur (tolerant
to failures).
• Intelligible: Readable (generally as a result of good coding style) and easily able to isolate
data and operations carried out on the data.
• Reusable: The desired analogy is the concept of software components being as widely
reusable as electronic components. In order for a library of components to be reusable, it is
essential that each is fully documented and characterised.

2.7.4 Software Design Process Assurance

The software life-cycle is a subset of the system life-cycle, as illustrated in Figure 2.30. Interac-
tion includes the exchange of data between the system and software life-cycles, categorisation
of failure conditions and software design quality assurance level determination, architectural
considerations and verification considerations. The system development life-cycle is described
in Chapter 6.
RTCA-DO-178 [7] (now at version C) provides guidelines on the software design process
for developing airborne software. The document comprises 12 interrelated sections as shown
in Figure 2.31. It establishes considerations for developers, installers and users of aircraft
equipment using embedded microcomputer techniques, and outlines verification, validation,
documentation and configuration management and quality assurance disciplines [6]. It is a
means (but not the only means) to secure approval by the certification authorities.
RTCA-DO-178 assigns software design quality assurance levels in accordance with the
safety categorisations as shown in Table 2.2.
The software development process is a series of sequential phases progressively refining
requirements to fully characterise the end product as illustrated in Figure 2.32. Entry and exit

Airworthiness
Requirements

System
System Life-Cycle Processes
Operational
Requirements System Safety Assessment Process

System Requirements
Allocated to Software Fault Containment
Boundaries
Software Level(s)
Error Sources
Design Constraints Identified/Eliminated

Hardware Definition Software

Requirements &
Archive

Software Life-Cycle Processes

Figure 2.30 Interaction between the system and software life-cycles

46 Civil Avionics Systems

System Aspects Relating to Overview of Aircraft and

Software Development Engine Certification
- Section 2 - Section 10

Software Life-Cycle Processses

Software Life Cycle - Section 3

Software Planning Process - Section 4

Software Development Process - Section 5

Integral Processes

Software Verification - Section 6

Software Configuration Management- Section 7

Software Quality Assurance - Section 8

Certification Liaison - Section 9

Software Life-Cycle Data - Section11

Additional Considerations - Section 12

Figure 2.31 RTCA-DO-178 software design process assurance

criteria are required to be specified for each phase. The philosophy is that correctness should
be achieved during development rather than by subsequent elimination.
Each step in the recommended design process has a set of prescribed objectives, and
activities or guidance for the process step, the rigor of which is moderated by the design
quality assurance level.

• Traceability: Maintained through all levels of decomposition.

• Validation: Determine that the requirements are correct and complete and that the results
have an adequate margin of safety consistent with its expected utilisation within its frame-
work of application.