Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > T&M

Adopting aerospace verification standards (Part 1)

Posted: 19 Sep 2013 ?? ?Print Version ?Bookmark and Share

Keywords:DO-178C? avionics? MISRA? verification? high-level languages?

The ever increasing reliance on software control has led numerous companies to take on safety-related analysis and testing. Consider the antilock braking and traction control of today's automobile. These safety systems are each managed by software running on a networked set of processors; the failure of any of these systems sparks major safety concerns that could lead to recalls and lawsuits.

Companies concerned about safety in their products are looking outside their own market sector for best practice approaches, techniques, and standards. Examples of such industry crossover have been seen in the automotive and avionics industries with the adoption of elements of the DO-178C standard by automotive and a similar adoption of the MISRA [3] standards by avionics.

Historical background: DO-178C
In the early 1980s the rapid increase in the deployment of software in airborne systems and equipment resulted in a need for industry guidelines that satisfied airworthiness requirements. Document DO-178, "Software Considerations in Airborne Systems and Equipment Certification," was written by RTCA [1] and EUROCAE [2] to meet this need.

In 1992, a revised version, DO-178B, was published. DO-178B went on to become the defining standard by which aerospace companies worldwide develop systems and software. Given the success of that standard, it was no surprise when its 2011 successor, DO-178C, adhered to the same principles. In addition to clarifying the interpretation of previous guidelines, the primary changes concern contemporary development techniques and address the use of formal methods, model-based development, object-orientated technologies, and software tools.

DO-178C is primarily a process-oriented document. The standard defines objectives for each process and outlines a means of satisfying the objectives. A system safety assessment process determines the significance of failure conditions in the system and its software components. (The more significant the system, the more severe the consequences should it fail.) This safety risk assessment forms the basis for establishing the infamous A-E software levels, which correlate the level of effort required to show adherence to certification requirements with the extent of risk associated with a system.

DO-178C Level A, Section 2.3.3 of the DO-178C standard defines software levels: "Level A: Software whose anomalous behaviour, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft."

This type of safety analysis is becoming ever more applicable to automobiles, nuclear power plants, MRI scanners, and financial systemsin fact any system where failure has major implications.

The challenges of more stringent safety testing standards

In adopting out-of-sector quality and testing standards, new and unfamiliar development and testing techniques need to be implemented, potentially including:

???Conformance to a set of coding standards, such as MISRA-C [4] or JSF++ AV [5], becomes a mandatory requirement for the software and companies that are adopting tools to automate code checking.
???Formal unit testing that demonstrates requirements are satisfied as they are incrementally implemented. This is often used alongside informal debugging.
???Code coverage analysis that validates the effectiveness of testing and exposes non-executable code.
???Full code coverage analysis down to the object code level of critical software components.

Coding standards
Restrictions on the use of certain language features have been around almost as long as high-level languages themselves. Global variables have been frowned on since the introduction of subroutines, and programmers using "goto" statements had better have a good reason for it. Such guidelines, while restrictive, avoid the runtime errors likely to result from their use.

For many reasons, such as its inherent flexibility and its potential for portability across a wide range of hardware, C became the language of choice for the development of real-time embedded applications within the automotive industry. C has most of the features a software development team could wish for and, in the right hands, it can be used to write well laid out, structured, and expressive code. In the wrong hands, however, its flexibility can result in extremely hard to understand code. Clearly, this is not acceptable for a safety-related system.

1???2???3?Next Page?Last Page

Article Comments - Adopting aerospace verification stan...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top