DO-178C – Software Considerations in Airborne Systems and Equipment Certification is a standard used in the aerospace and military/defense industries to promote reliable implementation of safety critical software. DO-178C is the primary document by which certification authorities like the FAA, EASA and Transport Canada approve all commercial software-based aerospace systems.
Over the last couple of years, makers of Military/Defense Aircrafts are seeing increased demand from their customers to build DO-178C compliant products. DO-178C compliance is highly rigorous and achieving certification is always challenging. Understanding these complex restrictions and guidelines are necessary to obtain FAA certification.
Our services are enabling our customers to leverage model-based development, testing and verification to meet certification requirements. EXB Solutions offers a comprehensive review of existing standards, consulting, expertise and engineering services to help you achieve solutions for DO-178C compliance.
Visual Summary of DO-178c Processes
As a member of the RTCA, our engineers have the expertise on the understanding of new standards, necessities and applicability contained in DO-178C. We offer various consulting services including EXB Gap Analysis, Evaluation of Tools and DO-178C Software Engineering Planning Processes.
1) EXB Gap Analysis can cover:
2) Evaluation of tools for Model-Based Design
3) The DO-178C software planning process is comprised of five significant areas:
EXB’s team of engineers experienced with DO-178C best practices will help you design and implement this software planning process to achieve compliance throughout your software development lifecycle.
At EXB, you’ll find tailor-made business solutions and delivery models that integrate into your existing work plans effortlessly. We offer multiple engagement models to help accelerate the delivery of your projects. EXB offers everything from a single, subject matter expert, to fully outsourced software teams.
Visual Summary of V-Model
What is DO-178 Compliance?
Compliance satisfaction (as defined in DO-178C): Compliance is achieved when all applicable objectives have been satisfied by performing all planned activities and capturing the related evidence. You will sometimes hear people use the term “certified” and sometimes use the term “certifiable”. Software that has been “certified” meets the objectives defined in DO-178C for the design assurance level dictated by a project’s system safety assessment and has been given a type certificate by a civil aviation certification authority such as the Federal Aviation Administration (FAA) or the European Aviation Safety Agency (EASA) showing the authority agrees that the software complies with the applicable regulations. Software that is “certifiable” has been developed in a way that meets the objectives of DO-178C for a given design assurance level but has not been approved or given a type certificate by a certification authority. DO-178C objectives include plans, up to two levels of requirements, software design, requirements-based tests, change tracking, configuration management, traceability between artifacts, and more. Refer to Annex A of DO-178C for all objectives.
What are the various DO-178 software levels?
There are five software levels in DO-178. The software level definitions are:
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.
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 hazardous/severe-major failure condition for the aircraft.
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 major failure condition for the aircraft.
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 minor failure condition for the aircraft.
Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function with no effect on aircraft operational capability or pilot workload. Once software has been confirmed as level E by the certification authority, no further guidelines of this document apply.
What is the difference between DO-178B and DO-178C?
DO-178C adds clarifications to common questions that arose from the use of DO-178B. The most significant change is the addition of new documents for the specific topics of tool qualification (DO-330), model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333).
Can you apply DO-178 reverse engineering to your existing software?
Creating DO-178 life cycle data for previously developed software has been done. However, this is not a trivial task for more critical design assurance levels. This can be especially difficult if the reverse-engineering team does not have access to the original developers of the software to ask for clarification on complex or undocumented code. For more details on the process and concerns of this topic, refer to Certification Authorities Software Team position paper CAST-18: Reverse Engineering in Certification Projects.
Is DO-330 required for DO-178C Certification?
It is possible to create DO-178C compliant software without the use of tools qualified using DO-330. A tool only needs to be qualified if it eliminates, reduces, or automates the process of meeting a DO-178C objective and the tool’s output is not verified. Many unqualified tools are used to increase productivity or automate mundane, repetitive tasks. Their use is acceptable because their output is verified. There are different levels of tool qualification based on what the tool does and how it is used. For higher criticality software, qualified tools that eliminate, reduce, or automate processes can be worth the cost because of the large amount of life cycle data that needs to be captured.