Embedded systems engineers designing real time aerospace and defence systems must meet stringent safety requirements. Boris Sedacca asks whether using common-off-the-shelf electronic hardware compromises safety.
The cost of software safety assurance compared to the cost of not having a safety assurance regime in place is rather obvious. The requirements of the regulations under safety legislation apply to a multitude of markets, including DO-178B and C standards in aerospace. Programming languages such as C++ and Ada simplify the coding of real time embedded systems in aircraft and motor vehicles but checking the results is more difficult. The use of formal methods of development for rules and standards in safety-critical software goes some way towards a solution.
The DO178B or C requests the applicant to fulfil objectives, but not the way or processes to achieve it, says Pascal Heude, Senior cost estimator at Airbus Operations SAS in Toulouse. COTS (common-of-the-shelf) can be used in two different ways: 'tools' like SCADE, RTRT, or 'embedded' like real time OS and compiler libraries.
"In the case of embedded COTS, DO178x objectives apply, which can be difficult if you do not have all the artefacts or evidence like source code," cautions Huede. "Using qualified tools is the only way to reduce the cost of development, by partially or fully removing the assessment of some objectives.
"There are two kinds of qualified tools, for DO178B: verification and development. Many tools can automate and/or eliminate some objectives: a requirements management tool can generate the traceability matrix and coding rules checker."
Kevin Kinsella, Architect of Global Hawk Avionics and Power at Northrop Grumman, argues that verifying safety critical software for a COTS aerospace system is more than just a DO-178 issue and use of formal coding methods.[Page Break]
Control loading system
Kinsella says: "System verification can be successful when the software is executing in the context of a redundancy management system, and the system is then subsequently tested on a Control Loading System (CLS) and six degree of freedom (6DoF). Testing fails each and every signal in the system one at a time, in order to verify the system can detect and isolate it, and continue to function safely.
"Hardware redundancy management is achieved when the system is running duplex, triplex or quad flight computer/sensor combinations. So for a given signal, say an actuator position or an air pressure sensor, you have to make a list of how it can fail, then inject each of the failures and see how your system reacts.
"If you have a failure, you want it to happen in the safety of a laboratory or in a simulation, and not to catch you by surprise in flight. When you are finally out flying, and that signal fails, you then know your system can detect it and safely react to it," he concludes.
In the DO-178C update to DO-178B, there is new guidance for the use of formal methods, as well as object oriented techniques (OOT), and also a 'Model Based Development and Verification' supplement. Steve Morton, Principal Engineer at Hawker Beechcraft holds that assuming the use of OOT, C++ and Ada actually complicate the translation of necessarily functional requirements allocated to the software into object-oriented architecture and design.[Page Break]
Reverse engineering of requirements
"For COTS, the problem tends to be considerably more complex than verification," Morton contends. "COTS being developed to a much wider market than aerospace commonly includes functionality that isn't intended by the aerospace application.
"Further, the reverse engineering of requirements and design data should necessarily end with at least some changes to the COTS software. Being in a lower software level category may alleviate some of the issues, but COTS when it isn't 'aerospace COTS' may always be problematic, given that safety must necessarily win out."
David Berlin, consulting aerospace software engineer, adds: "Take the price of a 737, divide by the number of passengers over 20 years, and I get a figure of about $22. This includes maintenance but the main issue is design cost. So even if safety, both in software and hardware, is half the price of the aircraft, that is $11 per flight.
"I used the 20 year figure which is pretty common for airframes, but it should also be noted that some avionics software written 20 years ago is still being installed in new aircraft today because we made sure it worked. Conversely, consider the cost of pulling a whole fleet of aircraft in to correct a tiny little coding error. That can run into millions.
"I would disagree that Ada simplifies the coding process, unless you compare it to assembly language, which it was designed to replace - quite the opposite, because of the strong typing and exception handling, which is why I prefer Ada. C is easy to code, and equally easy to allow fatal errors."
Quentin Ochem, technical account manager at AdaCore, agrees that checking result with Ada is easier than languages such as C. "This is the case only in the right subset though - removing too dynamic or too complex features - but that is fairly easy to do," he says.
Thales has chosen the AdaCore GNAT Pro technology, including several safety-qualified tools, to develop critical systems for the new Airbus A350 XWB extra wide body family. Thales will use GNAT Pro and the Ada 2005 language to build the Air Data Inertial Reference Unit (ADIRU), to provide precise in-flight positioning information. It will meet Level A of the DO-178B standard and use ARINC 653 multi-partition operating system MACS2.[Page Break]
Ochem continues: "With static analysis and proof, you have a range of tools from bug finders to real provers. The key is that Ada allows developers to express a wide range of properties that can be verified and natural to write.
"At the other end of the spectrum, the SPARK technology, which is a safe Ada subset extended with formal annotations, has been used for over 20 years. It allows developers to formally prove various properties and is exempt of all kind of vulnerabilities."
At Marshall Aerospace in Cambridge, UK, a pensioned off USAF C-130 aircraft was acquired by the Royal Netherlands Airforce (RNLAF) with the intention of extending its useful life. Prior to entry into service it was necessary for the aircraft to receive a number of upgrades and modifications in order to comply with EU legislation. The flight-deck was entirely upgraded with digital equipment replacing all previous analogue devices.[Page Break]
Failure modes and effects analysis
One key requirement was to perform a failure modes & effects analysis for the flight-deck to ensure no undesirable effects would propagate to the mission level as a result of the upgrade. The analysis was performed by Fraser Mackie, owner of ILS Complete in Munich, with personnel responsible for training individuals on the new equipment.
Mackie reveals from previous experience: "The majority of software events/failures I have encountered, whether it be COTS based or bespoke design, have been the result of change in specification external to the equipment for which it was designed. In those cases the software was doing exactly what it was designed to do despite leading to an unfavourable event. For example, a COTS based device I was using was processing radar data, when some months later, intermittent and ominous readings from the device would appear on the display. Fortunately the controller identified the track data as an error. Had the mistake not been identified there was a real risk tracks would be labelled incorrectly. The COTS device was replaced, but this did not fix the fault.
"Weeks of fault finding later it was discovered a replacement cable interfacing the COTS device to the system was replaced at the time the failure occurred. The cable was within electrical specification but for one key difference, its length. The increased length of the cable had meant the software on the COTS device could not handle the increased periods of time it took to retrieve data, process it, and send it to the display. Instead it took its best guess and sent the data anyway."
COTS is an emotive subject for Chris Andrews, product marketing manager at C-MAC Aerospace, who believes that in some ways, it is the enemy of his business as customers strive to cut costs by using commercial grade parts for harsh environment applications. He says: "It is hugely controversial in the space market in particular, where the added issue of radiation tolerance hinders the life of electronics.[Page Break]
Lot homogeneity
A key requirement for high reliability applications is lot homogeneity, continues Andrews. Even lots of semiconductors having the same date code may use chips from different wafer lots as the date code is sometimes applied after final test. In order to verify a lot of COTS components are fit for purpose, extensive dynamic and climatic testing is often required. This can end up costing more than the cost of high reliability parts thereby defeating the object.
General Dynamics UK uses Escher Technologies' Perfect Developer (PD) to specify and design a safety-critical airborne stores management system. Guy Mason, senior software engineer at General Dynamics UK says: "Our need is to meet the requirements of defence standard 00-55 to Safety Integrity Level 4. Escher Technologies software met our requirements best. We were especially impressed by the automation of verification proofs, which will substantially reduce our costs, and by the level of support provided by Escher Technologies.