Instrumentation • Electronics
4Embedded 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.
COTS must cut costs safely in aerospace and defence embedded design
T
he 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.
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
30
www.engineerlive.com
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.
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
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36