Adopting aerospace development and verification standards: Part 1 – A coding standards survey
An ever-increasing reliance on software control and the nature of the applications has led many companies to undertake 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  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  and EUROCAE  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 behavior, 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 systems — in 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  or JSF++ AV , 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.
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.
Recognizing the widespread use of C through compilers and tools, MISRA published their C standard to promote the use of “safe C” in the UK automotive industry. The standard quickly found a home in all applications, and MISRA now seeks only to promote the safest possible use of the language. The guidelines encourage good programming practice, focusing on coding rules, complexity measurement, and code coverage to ensure well-designed, adequately tested code which ultimately results in safer applications. The standard’s success has led to improved versions, first MISRA C:2004 and then MISRA C:2012.
The standard is extremely flexible, allowing particular rules to be omitted with appropriate justification. The 2012 version does include some mandatory rules, however. The following summary of such a rule gives you a sense of the standard and its aim:
With the increased dependency on software in complex systems, more programming languages are being used. C++ is expected to become a major player in future software projects across all industries. However, the MISRAC standard does not comment on the suitability of C++ for use in safety-related systems, and this presented a problem to Lockheed Martin when it decided to standardize on both C and C++ for the key avionics control systems of the Joint Strike Fighter (JSF). Lockheed Martin decided to build on the MISRA C guidelines by adding an additional set of rules specific to the appropriate use of C++ language features (e.g., templates, inheritance). The result was the JSF Air Vehicle (AV) C++ coding standard, which ensures that all compliant software is developed to a consistent style, portable to other architectures, free from common errors, and easily understandable and maintainable by any team member. The JSF AV standard was a major step forward in the use of C++ within safety-related systems.
However, the opinion across industry and relevant organizations was that JSF AV was best for JSF and not ideal as a general solution. To gain broader applicability, MISRA developed a C++ standard in 2008, building on the JSF AV foundation. With well-formed, peer-reviewed standards for both C and C++ managed by one organization, software teams are now able to rely on cohesive and uniform guidelines for the principal embedded development languages.
This consistency of standard has helped the industry transition from manual compliance checking - which is tedious, error prone, and time consuming - to automated methods. Automated methods have the added benefit of being able to demonstrate to a certification authority that the source code is 100% conformant. The use of tools to automate the code review process has created a fast, repeatable process with quality reports that enhance the efforts of the development team.
The MISRA programming guidelines, when used within the process framework of DO-178C, provide an extended development model that addresses issues of both quality and reliability. Less obviously, projects adopting this joint approach also experience significant cost savings, and that can only benefit non-aerospace industries as the need for quality increases.