Ada at Barco avionics
Ludovic Brenta
Ada-Belgium General Assembly, 2007-06-12
Copyright (c) 2007 Barco NV.
Permission is granted to make and distribute verbatim copies of this document. Modification is not allowed.

Barco Avionics
• One of the seven divisions of Barco NV
• Established in 1998
• Growing fast
• We are hiring!

Eurocopter Tiger

T-33 Minuteman

BE-200

P-3D Orion

Retrofit on RC-135 (during, after)

Pilatus PC-21

What's so special about avionics
• Certification requirements
– We obey the civilian DO-178B recommendations
– or the customer's military standard if applicable
• Long life-times
– Development of an aircraft: 8-10 years
– In-flight service: 30-50 years
– Avionics cycles can be shorter because of upgrades
• Hardware constraints
• Typical development schedule
– Development, testing and certification: 2-3 years
– Maintenance: 20+ years
– (our first products are still being maintained)
– We have contractual obligations to keep an inventory
of spare parts

What we do
• Design and manufacture processor and other boards
– using COTS or custom-made components
– factory in Poperinge, also serves rest of Barco
• Design and manufacture power supplies
– the power supply in an aircraft is very unpredictable
– but the electronics requires very reliable supply
• Design keyboards and other mechanical parts
– subcontractors make the keyboards, LCDs, cases etc.
• Design and assemble the \"optical stack\":
– LCD, backlights (lamp and LEDs), special glass panels
• Design, implement and test the software
– Firmware (\"boot software\")
– Application software
• Assemble the units in Kortrijk
• Design and implement the testing procedures
– Vibration, electric static discharge, temperature,
moisture, Hightly-Accelerated Life Testing, etc.

Control Display and Management Units
• A dumb text-only terminal
– Only uppercase characters
(large and small)
– With 8 glorious colours!
• Linked to several on-board
computers
– (hence \"multi-purpose\")
– flight management
computer
– mission computer
– etc.
• Uses either ARINC 739 or
MIL-STD-1553 buses

Internal architecture of CDMS (1994)
• First generation (1994)
– 64-bit RISC microcontroller, 1024
instructions max
– Electroluminescent display (not LCD)
– Monochrome (amber)
– Programed in assembly language

Internal architecture of CDMS (1998)
• Second generation (1998)
– MPC68360 \"QUICC\" processor (68000 core, 25 MHz)
– 512 kb RAM, 512 kb Flash
– Quarter-VGA (320x240) LCD
– Programmed in Ada 83 with CSMART (Certifiable SMall Ada Run-
Time) from Alsys
– Separate ARINC board
with XScale µcontroller
– Separate keyboard and
display with XScale µc

Internal architecture of CDMS (2007)
• Third generation (2007)
– PowerQUICC II processor
• PowerPC 603e core, 16+16k cache, 450
MHz
– 256 Mb RAM, 512 Mb Flash
– Full VGA display (640x480)
– Video capable
– On-board ARINC FPGA
(programmed in VHDL)
– Programmed in Ada 95, pragma
No_Run_Time

Multi-Function Displays
• Smart graphical terminal
• Connected via ARINC 429 or MIL-STD-1553
buses to multiple computers
– Air Data Computer (airspeed, pressure
altitude, etc.)
– Global Positioning System
– Inertial Reference System
– Radio altimeter
– Autopilot
– Navigation computer (VOR, DME, ILS, etc.)
– Weather radar
– Other subsystems and sensors: engines, fuel,
etc.
• Various push button and rotating knobs on
all four sides
– Depending on customer, of course

Multi-Function Displays
• 5\"x4\"

Multi-Function (here Primary Flight)
Displays
• 6\"x8\"

Multi-Function Displays
• 6\"x8\" with separate processing unit

Multi-Function (another Primary Flight)
Displays
• 12\"x9\" (not yet sold)

Internal architecture of Multi-Function
Displays
• Symbol Generator (2002)
– PowerQUICC
• PowerPC core, 16+16k cache, 100 MHz
– 32 Mb RAM, 32 Mb Flash
– Programmed in Ada 95 with Minimal Ada Run-time
Kernel (MARK, from Rational Apex)
• Symbol Generator II (2006)
– Mostly identical to third generation of CDMS
– PowerQUICC II
• PowerPC 603e core, 16+16k cache, 450 MHz
– Optional PowerPC G3 (MPC755)
• 32+32k cache, 1 Mb L2 external cache, 400 MHz
– 256 Mb RAM, 512 Mb Flash (more in the future)
– Programmed in Ada 95 with pragma No_Run_Time
– Uses a COTS real-time operating system

Trends in avionics displays
• The displays' processor boards are ever
more powerful
• Goal: eliminate physical computers
from the aircraft, run their software
inside the display
– (autopilot, flight management sytem,
etc.)
–Challenges:
• introduce multitasking into the display
• logical partitioning between applications
• hard real-time requirements, different for each
app
• certification requirements, different for each
app
• communications between apps using shared
memory

MOSART
• Modular Open Systems ARchiTecture
– An API we build our apps on
– We also offer it to customers who want to write their
own apps
– Provides device drivers and built-in tests for all
components of the display

History of Ada at Barco (1)
• 1986 - Barco decides to enter the avionics market
– First product: a CRT video display
• 1994 – First product with embedded software
– CDMS programmed in assembly language with 1024
instructions
– No software or hardware engineers - just \"engineers\"
• 1998 – First Ada training
– Only two people trained: the senior \"engineers\"
– First internal tool (native) using ObjectAda
• Separation into hardware and software teams
– Hire a software development manager
– Has experience with Ada in nuclear simulation
– First embedded project uses C-Smart, Alsys Ada (83)
and Rational Apex
– Introduces UML (later abandoned)
• 2001 - Ada 83 coding standard
– Written by a consultant from KU Leuven

History of Ada at Barco (2)
• 2004 - Start of Mosart development
– Language question revisited
– Stay with Ada due to inertia
– Provide a C binding to Mosart for customers
• 2005 - Ada 95 coding standard
• 2006 - Second wave of Ada training
– Ada Basics by yours truly
• May 2006: 2 new hires + 1 C developer
• January 2007: 1 new hire
– Ada Advanced by Adalog
• September 2006: 11 developers
– Contents tailored for avionics

DO-178B certification (1)
• DO-178B: \"Software Considerations in Airborne
Systems and Equipment Certification\"
• Defines 5 levels of criticality depending on the
consequences of a failure
– Level A: catastrophic (aircraft crashes)
– Level B: hazardous (aircraft flies but is crippled)
– Level C: serious
– Level D: pilots are annoyed
– Level E: passengers are annoyed

DO-178B certification (2)
• Certification requires three \"stacks\" of documents:
– With traceability between items in each document
System requirements Verification of System requirements
Testing procedures Software requirements Verification of Software requirements
Verification of Software design Verification of Software design
testing procedures
Verification of Low-level requirements
Low-level requirements
Results of testing
procedures
Source text Verification of source text
Object code Verification of object code

DO-178B certification (3)
• Additional documents required for certification:
– Software development procedure
– Design standard
– Coding standard
– Verification that the software development procedure
has been followed
• Waivers in case of deviations
– Verification that the design standard has been
followed
• Waivers in case of deviations
– Verification that the coding standard has been
followed
• Waivers in case of deviations

DO-178B certification (4)
• Level A: full stack required
– In particular: traceability between source text and
object code
• Requires support from the compiler
• Main concern of the coding standard
– With independence
• i.e. the person who verifies is not the person who writes
• Level B: only down to source code
– Object code not verified
– With independence
• Level C: only down to source code
– Independence not required

Coding standard: why (1)
• We are required to have one, per DO-178B
• Uniformity of source text
• Portability
• Maintainability
• Avoid dangerous constructs
– Infinite loops
– Dynamic memory allocation and deallocation
– Aliasing
• Allow dangerous constructs (!)
– Low-level access to hardware
– Memory-mapped devices
– Machine code insertions

Coding standard: why (2)
• Make it easy to test the software
– All subprograms and package variables must be
declared in spec
• (except instances of Ada.Unchecked_Conversion)
– Unit tests are child packages
• Help trace source text to object code
– Be aware of \"hidden\" object code
• Range checks
• Access checks
• Tag checks
• Exception propagation
• Functions returning objects of unconstrained types
• Secondary stack
• Variant records
• Tags and dynamic dispatching
• Changes of representation during type conversions
• etc.
– Reduce the amount of \"hidden\" object code

Coding standard: how
• For each language feature:
– Usage is allowed: no problem
– Usage is allowed with documentation:
• Comments required in source text
• Justification required in source text or design document
– Usage is disallowed:
• No excuses accepted
• The rules depend on the criticality level
– Level A: \"high\" - traceability to object code req'd
– Levels B .. D: \"medium\"
– Level E: \"low\" - everything except goto is allowed

Coding standard: examples (1)
• Functions returning objects of unconstrained types:
– Level A .. C: disallowed; levels D .. E: allowed with doc
• General access types
– Disallowed, except
System.Address_To_Access_Conversions
– Consequence: no silent aliasing
• Anonymous access types
– Disallowed: they introduce aliasing
• Tagged types: allowed
• Discriminants with default values
– Require Size representation clause: size may not
change
• Compiler-dependent packages disallowed
– Except System.Machine_Code

Coding standard: examples (2)
• Allow low-level programming features with
documentation:
– Overlays
– System.Address_To_Access_Conversions
– Machine code insertions
– pragma Volatile, pragma Atomic
– Full rep clauses required (pragma Pack not sufficient)
– pragma Import, pragma Export

Coding standard: examples (3)
• Dynamic dispatching
– Not yet widely accepted in avionics
– Certification authorities are wary
– Why:
• Not sure which subprogram is called
• Not sure there is a subprogram to call
• Dangers of “down-casting”
• Call of abstract subprograms
– Rules:
• Level A: disallowed (pragma Restrictions (No_Dispatch) required)
• Level B .. D: allowed with documentation (dispatching calls must
be identified)
• Level E: allowed
• Polymorphic collections (e.g. array of access to class-wide type)
must be static
• Tagged types and type extension are always allowed

Coding standard: examples (4)
• Tasking
– Level A: disallowed
– Level B .. D: Ravenscar only, with documentation
– Level E: allowed
– Requires a run-time kernel which must also be certified
– Requires analysis of the scheduling
• Our current practice
– No tasking used in existing products
• CSMART: no tasking provided
• MARK: no tasking provided
– Tasking provided by the RTOS in products currently in
development (using MOSART)