Ada at Barco avionics

2,347 views

Published on

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

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,347
On SlideShare
0
From Embeds
0
Number of Embeds
30
Actions
Shares
0
Downloads
71
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Ada at Barco avionics

  1. 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. 2. Barco Avionics • One of the seven divisions of Barco NV • Established in 1998 • Growing fast • We are hiring!
  3. 3. Eurocopter Tiger
  4. 4. T-33 Minuteman
  5. 5. BE-200
  6. 6. P-3D Orion
  7. 7. Retrofit on RC-135 (during, after)
  8. 8. Pilatus PC-21
  9. 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. 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. 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. 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. 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. 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. 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. 16. Multi-Function Displays • 5quot;x4quot;
  17. 17. Multi-Function (here Primary Flight) Displays • 6quot;x8quot;
  18. 18. Multi-Function Displays • 6quot;x8quot; with separate processing unit
  19. 19. Multi-Function (another Primary Flight) Displays • 12quot;x9quot; (not yet sold)
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)

×