INTRODUCTION:
DO-178C – “Software Considerations in Airborne Systems and Equipment Certification” – provides production guidelines for software that is to be used in airborne systems, and equipment that consequently must “comply with airworthiness requirements.” Software development to DO-178B/C Levels A and B, in particular, require rigorous verification and validation, plus development to strict guidelines and processes.
Developing software for airborne systems is expensive, risky, and time consuming. Static analysis tools are an important part of the safety-critical software development tool chain, and play an important role throughout the software lifecycle. This post summarizes the applicability of our tools and how they can reduce the cost and risk associated with DO-178B/C development.
Related:
- Virtual Integration for Improved System Design
- Simplifying DO-178C Certification with GrammaTech’s CodeSonar
- DO-178C Benefits Versus Costs
The Safety-Critical Software Affordability Wall
Software has become the leading single-cost center for aircraft development, with one-third of new airplane costs in software and software development. Software has afforded amazing new capabilities, but its exponential growth and associated costs (especially of DO-178B/C Level A and B criticality levels) have made it effectively unaffordable (Source: SEI, “Virtual Integration for Improved System Design“, Redman et. al, 2010). In order to maintain strict safety standards and increasing functionality, something needs to change. Adopting new tools and processes and reusing/buying software components can help break through the affordability wall. Our whitepaper about making safety critical software more affordable goes into more detail, if you are interested in reading more on this topic.
Integrating Static Analysis into DO-178B/C Software Development Process
The use of GrammaTech’s CodeSonar is most applicable to DO-178C chapters 6, 7, 11, and 12. However, static analysis tools can also support various activities and objectives from other chapters. In particular, CodeSonar can provide value throughout the Software Development Process (chapter 5), and the completion of a CodeSonar analysis – perhaps with a limit on the permissible number of warnings – is a useful transition criterion (chapter 4) in many cases.
Our whitepaper Simplifying DO-178B Certification with GrammaTech’s CodeSonar goes into more detail about how CodeSonar complies with various DO-178B/C directives.
Configuration Management and Software Lifecycle Support
CodeSonar is not a software-configuration management tool, but it can interact with the software-configuration management process in several useful ways. Once integrated into the development process, the analysis results become part of the lifecycle data (in a good way, by providing proof of compliance) and as such, need to be managed. CodeSonar helps by providing the following:
- Traceability via unique identifiers and annotations
- Problem reporting and tracking via the CodeSonar hub
- Change-control via records of each past analysis with traceability
- Change review via CodeSonar’s comprehensive web interface (which displays annotations, versions, and tracking information)
- Enforcement of software coding and design standards
CodeSonar’s combination of source and binary analysis plays a critical role in analyzing previously-developed software (DO-178B Chapter 12, “Additional Considerations”). Trusting and understanding re-used code is important in order to ensure it meets the same standards as the rest of the system, and holds up to verification and validation scrutiny. If source is not available, CodeSonar’s unique binary analysis can inspect libraries, object files, and executables for defects and security vulnerabilities. Although remediation might not be possible, it provides evidence to bring to software vendors and developers.
Risk and Cost Reduction with Static Analysis
Static analysis tools provide tangible productivity improvements to software teams seeking stringent software safety certification. Using a qualified tool as part of the software development process from early stages of development can have significant benefits.
- Code coverage isn’t everything: DO-178B/C requires increasingly demanding levels of code coverage (proof that tests execute most, if not all, statements and conditions), depending on the criticality of the software. Although this is very exhaustive, it’s very expensive to do and must be repeated in each major phase of development (unit, integration, and system testing). Testing code coverage is one metric to evaluate software quality by, but there are cases where it doesn’t catch everything.
- Bugs that coverage-based testing miss: Testing software based on coverage metrics is inherently unit-based (although coverage is evaluated at a system level as well). Concurrency errors and security vulnerabilities are two key instances of defects that can be missed even during rigorous testing. Concurrency is often tough to program correctly and can yield errors (e.g. race conditions) that are undetected until some unforeseen condition during operation. Security vulnerabilities do manifest as bugs in the code — the conditions creating the error are often due to types of input not considered during testing. Static analysis can discover these errors early and prevent them from being show-stoppers late in the development cycle.
- Detect defects early: Rigorous testing can discover most defects in software, but it’s expensive and extremely time-consuming. Discovering and fixing these bugs when writing the code is also considerably cheaper than later in the development cycle (defect discovery is exponentially more expensive over time). Static analysis can detect bugs in the code as it is written, as part of a developer’s development environment, greatly reducing the downstream cost of defects.
- Analyzing third-party software: Use of third-party code, such as commercial off-the-shelf software (COTS) and open-source software, is a fact of life in embedded software development. Some safety standards consider any software that isn’t developed to the specific standard as Software Of Unknown Pedigree (SOUP) — software that needs to be looked at carefully for inclusion in the system. CodeSonar can analyze third-party source and binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise (without including it and running it, an expensive option).
- Accelerate certification evidence: Static analysis (and many other testing and lifecycle management tools) provide automated documentation to support testing, coding standard, and quality/robustness evidence. Much of the manpower used in safety certifications is documentation and evidence production. Automation through the use of static analysis reduces this burden significantly.
CONCLUSION:
Static analysis tools can make a significant contribution to DO-178B/C development projects. Sophisticated static analysis provides multiple points of leverage for verification and re-verification, to decrease risks and costs. In addition, CodeSonar’s extensive reporting and record-keeping mechanisms provide support for various other DO-178B/C objective.
