By 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. http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/07/070612-abga-event.html

1. 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.

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

3. Eurocopter Tiger

4. T-33 Minuteman

5. BE-200

6. P-3D Orion

7. Retrofit on RC-135 (during, after)

8. Pilatus PC-21

9. 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

10. 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 quot;optical stackquot;:
– LCD, backlights (lamp and LEDs), special glass panels
• Design, implement and test the software
– Firmware (quot;boot softwarequot;)
– Application software
• Assemble the units in Kortrijk
• Design and implement the testing procedures
– Vibration, electric static discharge, temperature,
moisture, Hightly-Accelerated Life Testing, etc.

11. 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 quot;multi-purposequot;)
– flight management
computer
– mission computer
– etc.
• Uses either ARINC 739 or
MIL-STD-1553 buses

12. 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

13. Internal architecture of CDMS (1998)
• Second generation (1998)
– MPC68360 quot;QUICCquot; 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

14. 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

15. 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

16. Multi-Function Displays
• 5quot;x4quot;

17. Multi-Function (here Primary Flight)
Displays
• 6quot;x8quot;

18. Multi-Function Displays
• 6quot;x8quot; with separate processing unit

19. Multi-Function (another Primary Flight)
Displays
• 12quot;x9quot; (not yet sold)

20. 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

21. 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

22. 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

23. 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 quot;engineersquot;
• 1998 – First Ada training
– Only two people trained: the senior quot;engineersquot;
– 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

24. 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

25. DO-178B certification (1)
• DO-178B: quot;Software Considerations in Airborne
Systems and Equipment Certificationquot;
• 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

26. DO-178B certification (2)
• Certification requires three quot;stacksquot; 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

27. 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

28. 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

29. 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

30. 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 quot;hiddenquot; 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 quot;hiddenquot; object code

31. 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: quot;highquot; - traceability to object code req'd
– Levels B .. D: quot;mediumquot;
– Level E: quot;lowquot; - everything except goto is allowed

32. 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

33. 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

34. 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

35. 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)