Safety is of the utmost importance when it comes to the design of software for the aerospace industry, and no safety guideline has been as impactful as DO-178B, also known as Software Considerations in Airborne Systems and Equipment Certification.
What Is DO-178B?
Published in 1992 by Radio Technical Commission for Aeronautics (RTCA) and developed jointly with EUROCAE, the European Organization for Civil Aviation Equipment, DO-178B is an international guideline that deals with the safety of mission-critical software used in airborne systems and equipment. Even though it is just a guideline and not a policy, DO-178B is seen as a standard for developing avionics software, and even the FAA uses it for guidance when determining if a piece of software will perform reliably in an airborne environment.
Despite being developed specifically to meet the unique needs of the aerospace industry, DO-178B has seen use in other industries as well, often in conjunction with DO-254, also known as Design Assurance Guidance for Airborne Electronic Hardware, which deals with the development of airborne electronic hardware. Just like DO-178B, DO-254 is published by RTCA, a United States volunteer organization whose mission is to develop technical guidance for use by government regulatory authorities and by industry.
What difference between DO-178B and DO-178C?
DO-178B has been superseded by DO-178C, whose latest version was published in 2012. DO-178C improves upon the DO-178B by using clearer, more concise language and terminology, addressing inconsistencies uncovered from DO-178B Annex A, increasing and clarifying objectives for DAL A, B and C, and explicitly considering the impact of Parameter Data Item elements on multi-baseline and configuration-dependent software artifacts.
Overview of DO-178B
DO-178B describes five failure conditions, which are categorized by their effect on passengers, crew, and aircraft. Their effects are used to determine the Software Level, also known as the Design Assurance Level (DAL) or Item Development Assurance Level (IDAL). Software Level indicates the amount of effort that goes into the development of the given software application.
Level A (Catastrophic)
Failure prevents continued safe flight because it may cause a crash by disabling a critical function required to safely fly and land aircraft.
Level B (Hazardous)
Failure has adverse effects on occupants because it reduces the ability of the operators to operate the aircraft properly. Serious or fatal injuries may occur.
Level C (Major)
Failure doesn’t have such a large impact as a Hazardous failure, but it’s still very significant and greatly increases the workload of the operators and reduces the margin in safety.
Level D (Minor)
Failure doesn’t have such a large impact as a Major failure, but it’s still noticeable and may cause passenger inconvenience or a routine flight plan change.
Level E (No Effect)
Failure doesn’t affect operation capability at all and thus has no impact on the safety of aircraft or the workload of operators.
Reliable data on the costs associated with moving to a higher level are scarce, but the little data that are available point to an increase of development costs between 75% and 150%. The increase is caused largely by the increasing objectives to be met for each criticality level. DO-178B allows a great deal of flexibility when it comes to software development because of its objective-based nature since there are many possible ways for a real project to satisfy them.
A generic DO-178B process is divided into five distinct processes, with each process having a set of expected documented outputs:
Planning
Output documents include software development plan (SDP).
Development
Output documents include software requirements data (SRD), software design description (SDD), source code, and executable object code.
Verification
Output documents include software verification cases and procedures (SVCP), and software verification results (SVR) with the review of all requirements, design, and code.
Configuration management
Output documents include software configuration index (SCI), and software life cycle environment configuration index (SECI).
Quality assurance
Output documents include software quality assurance records (SQAR), software conformity review (SCR), and software accomplishment summary (SAS).
How to Support DO-178B?
There are many tools that can help in the DO-178B processes, including development tools, verification tools, and requirements management tools.
The last category of tools is especially important because it should be possible to trace back to the origin of each requirement during the DO-178B processes, and every change made to the requirement should, therefore, be documented in order to achieve traceability. In fact, the use of the requirement after the deployment of the implemented features should be traceable as well.
Developing DO-178B-compliant software for airborne systems without a software tool capable of providing deep and rigorous traceability of the project artifacts throughout all the stages of the development would be an impossible feat.
Supporting the DO-178B with a Requirement management tool
Requirement management tool such as Visure Requirements can support DO-178B by providing end-to-end traceability between all the requirements, verification, problem reporting, checklists and project artifacts. It offers a cohesive environment that acts as a centralized and open repository for all artifacts, including DO-178B objectives.
With Visure Requirements, it’s easy to standardize and enforce the defined processes across the organization to comply with the DO-178B guideline, and do so in an accessible, collaborative, and cost-effective manner.
Thanks to its versatile Integration Platform, Visure Requirements can integrate with third-party, commercial or proprietary, tools to extend the change impact analysis features to elements out of its scope in order to further support DO-178B.
Other requirements management features of Visure Requirements include filters, user-defined views, role-based user interface, graphically defined requirement process and traceability, built-in workflows, unlimited number of user-defined attributes, version management and comparison, and roll-back to older versions, among others.
Conclusion
DO-178B plays a critical role in the development of avionics software systems, but it places a major burden on those who attempt to satisfy the numerous objectives of each of its levels. The good news is that the DO-178B processes can be automated, assisted, or otherwise handled by various software tools, including requirements management tools like Visure Requirements.
