Airbus A380 in flight

Verifying safety-critical aerospace and automotive applications

Languages such as C++ and Ada simplify the coding of embedded systems in aircraft and motor vehicles but checking the results has been more difficult.

Engineers coding safety-critical systems today have plenty in the toolbox. The C++ programming language offers object-oriented technology, for example. As a result, it is relatively easy to implement the various bells and whistles that such systems require - the devil lies in making sure that they work.

To that end, the aviation and automotive industries are soon to introduce new rules and standards that aim to improve code verification and thereby deliver the especially high levels of functional safety they require.

In aviation, the Radio Technical Commission for Aeronautics (RTCA) is getting ready to publish DO-178C, the latest revision of its standard on Software Considerations in Airborne Systems and Equipment Certification.

Meanwhile, the automotive industry is working through the approval of ISO 26262, a road vehicle-specific version of the broader IEC 61508 standard on the functional safety on electrical, electronic and programmable safety systems. ISO 26262 was issued in draft form in July 2009 and is expected to be adopted as a full international standard towards the middle of 2011.


The current DO-178B edition of the RTCA's guidance on safety software development was approved in 1992. Obviously, much has changed since then, not merely in terms of how software is written but also its volume.

One further complication is that DO-178 is a civil standard and an additional set of rules applies to military aviation.

'The equipment that the military aviation sector procures is from companies that are mainly servicing the civil aviation industry, most of which use DO-178. DO-178 is a good starting point for any safety software development process, but will not be considered sufficient in military terms,' explains Brian Jepson, chairman of the steering group for Newcastle University's Safety Critical Systems Club (SCSC).

'Until a few years ago, there were the UK Defence Standards 00-55 and 00-56 describing the requirements for procedures and technical practices for the development of safety-related software.

'Defence policy is now less prescriptive in how to go about designing safety software and has changed to a more goal-setting approach. The latest version of 00-56 tells you what sort of framework customers require, such as managing safety and how to define goals and assess the management process - it does not tell us how to do it any more.'

In this context, Jepson says the defence industry falls back on guidance like DO-178 on a case-by-case basis to justify processes for the development of safety features within a final product.

Meanwhile, Europe's Joint Aviation Requirements (JAR) and North America's Federal Aviation Requirements (FAR) add yet more rules for software development.

In the civil sector, there are higher-level system requirements that state there must be no single point of failure in large civil aircraft but that they must have multiple redundant systems so that a backup is almost always available (although this often will not apply for defence projects as low weight may be a greater priority).

'You have to do extra validation to get up to the [most dependable] level of Safety Integrity Level 4 (SIL4), which is very similar to the SIL levels in IEC 61508,' says Jepson.

DO-178C will also address some specific shortcomings in its predecessor, says Jepson. 'DO-178 is weak in areas like static analysis or being able to demonstrate the properties of the software before embedding in a target product. It is also weak over the level of testing required for high-integrity applications,' he says.

'Tools like compilers can produce faults which are difficult to detect downstream in the development cycle. These are the areas that DO-178C will start to address. In the past, little was said about the use of formal methods and static analysis - some people say it was in there, but hidden.'

DO-178C is, in this respect something of a tidying-up. Another executive who sees much of it in this light is Tobias Knostmann, vice president of Central European Operations at Esterel Technologies, a supplier of model-based design, verification and code generation tools.

Knostmann goes so far as to say that that DO-178C is a patchwork of supplements called Certification Review Items (CRIs) that harden DO-178B and task papers that clarify it.

'It is all going to be cleaned up in DO-178C, taking in new development methods like object oriented methods and model-based design,' he says. 'DO-178B had loopholes and some developers were good at using them to obtain certification without fulfilling its objectives. It is all about interpretation, but DO-178C will clear up such uncertainties.'


The Motor Industry Software Reliability Association (MISRA) released the MISRA C software development standard for the C programming language in 1998. It established a set of 127 guidelines for the use of C in the design of embedded automotive safety-critical systems. As C is the de facto language for coding, such systems are also vulnerable to C errors, so it was felt that there was a need to restrict some of its features.

ISO 26262, entitled 'Road Vehicles - Functional Safety', will take things further, says Dr David Ward, head of functional safety at automotive engineering consultancy MIRA.

'It is really meant to be the automotive equivalent to IEC 61508,' Ward points out. 'ISO 26262 is concerned with the whole process of developing safety related systems, including hardware and software. It includes requirements for the management of functional safety - things like hiring a safety manager and competent people, as well as hazard analysis and risk assessment.'

Demand for such a regime is such that, although ISO 26262 is at the draft stage, some major US, European and Japanese vehicle manufacturers are already specifying it.

'People will obviously have different views as to the technical content, but there is unanimous international agreement to have a standard issued,' says Ward.

One common feature of standards like IEC 61508 and ISO 26262 is that they recommend the use of a large number of different measures and requirements to guarantee the specification, design and verification of robust software. One of those set down in ISO 26262 is the use of a language subset such as MISRA C.

'MISRA C is telling you specifically what you need to do with the programming language in the way that you actually write the code, but there are a lot more considerations in the way you design and test the system,' says Ward.

'In some ways, ISO 26262 is not asking for anything different because people have been following the various MISRA Guidelines, and indeed IEC 61508 directly, for a number of years. What it is now saying is that we will have a common approach in the standard, so suppliers will be able to develop to this standard, and produce work acceptable to the major vehicle manufacturers.'

Ward identifies a number of specific areas of interest and challenges to which this 'common approach' is being extended.

'Suppliers of tools to developers of software for vehicle safety will be interested in the explicit requirement for model-based development in ISO 26262, and for verifying that the tools themselves are fit for use,' he says. 'Relying on tools for automatic code generation has been addressed in a similar way with DO-178C.'


Much will depend on the vendors when it comes to enabling compliance with all these new or updated standards. Certainly, they are keeping aviation and automotive tool suppliers busy. One company keeping particularly close tabs on the standards' progress is The Mathworks. For example, it has been involved with development work towards DO-178C since 2006.

Tom Erkkinen, the company's Embedded Code Generation manger, says one area of particular focus has been the standard's content with regard to model-based development. This needs to fit into a process that has historically used paper documentation and hand coding.

Mathworks launched a tool qualification kit for DO-178B in early 2009 and Erkkinen envisages DO-178C will steer much of the company's future work on formal methods and appropriate tools.

'The model-based design supplement will also provide more clarity for our customers, particularly in the use of model coverage,' he says. 'For example, code coverage analysis tools test code to ensure it was invoked, otherwise you might have dead code. Likewise, when you start detailed design with a model, you have to know if the model has been covered. We have that capability already in a model coverage tool that we qualified in earlier 2010. We expect that there will be a stronger recommendation in DO-178C for model coverage.

'Customers will not use a model to test a model in the same way that they will not use code to test code. They need to use the higher version of an algorithm or requirement to figure out how to test the model. DO-178B will tell you not to test code by studying the code, but by studying the design requirement, and DO-178C also advocates requirement based testing.'

In the automotive sector, Mathworks has already had two ISO 26262 qualification kits certified for all SILs by the German Technischer 'berwachungsverein (TUV) technical inspection authority. The company has also released the certification and artefacts needed for IEC 61508.

'Mathworks PolySpace code generator and code verifier conduct a rigorous formal verification process on both Simulink-generated and hand-coded software to establish there are no run-time errors,' says Erkkinen. 'In practice, very few projects are exclusively hand-coded or exclusively model-generated; most projects use a mixture.'


The incoming standards and extensions to existing ones are not about the specifics of particular coding styles but rather entire business processes.

'DO-178 and IEC 61508 are full process guidelines spanning the requirements through testing to configuration/build management. So in the motor industry, MISRA C is very much one aspect of that wider process standard,' says Andrew Kay, manager of the Consulting Services Group at code analysis tool vendor PRQA.

Within each standard, engineers have the flexibility to choose whichever coding guidelines or testing tools they want. They should all encompass a strong set of best practices, but each is tailored to a specific industry. For some this is familiar territory, but not so much for others.

'Until ISO 26262 is released, automotive will not have had an umbrella process standard like DO-178,' says Kay. 'DO-178 has auditors to prove that projects conform to guidelines. The automotive sector has not really had an over-arching governing body as such, but a drive for quality and standards has come from software reliability associations like MISRA and large players in the market, like tier-one suppliers.'

So, while MISRA has long defined standards at the code level, ISO 26262 will now oblige project managers to prove that they have followed the required process.

By contrast, the changes with DO-178C for aviation developers will be more evolutionary. 'For example, a model-driven architecture for producing code may now start as a UML diagram at the highest level but aside from that, DO-178C is not a big jump from DO-178B,' says Kay.

Esterel's Knostmann agrees that the aviation challenge is more manageable. 'If you have a solid DO-178B process in place, there is no need to change it. DO-178B and DO-178C provide clear objectives, which users are free to fulfil in whatever way is thought feasible, and at the end a Designated Engineering Representative [DER] has to audit the project to confirm the objectives have been fulfilled.

'The DER comes from a notified body and analyses the software development process. Once satisfied, the DER tells the Federal Aviation Authority or Civil Aviation Authority that the objectives have been fulfilled, and that the software is certifiable. The DER can be in-house or external consultants. We do not have internal DERs because that could create a conflict of interests.'

It comes down to ensuring that a development environment follows principles outlined in the process standard using appropriate tools.

'Within DO-178, there are accredited external auditors in addition to the aviation companies' own internal auditors,' Kay concludes. 'It depends on the project requirement and the desired SIL safety level to be achieved, but there is an external body of auditors from the FAA, CAA or external companies with the expertise to conduct such audits.

'In the automotive sector too, I would hope that there is a level of abstraction away from the project environment, so that there is independent verification from a third party, or at least a separation internally between the QA team and the development team.'

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them