10 Best Practices to Achieve DO-178C Certification — Your Checklist!
News about data breaches and software failures grab headlines quite often. In our personal lives too, we deal with software glitches daily, starting from laptop crashes to mobile app failures. Similarly, in the sphere of civil aviation too, there has been extensive use of software in their safety-critical airborne systems. However, it’s not too often that we hear of fatalities caused due to software failures in aviation.
So, who ensures that the avionics software is functioning flawlessly? For commercial as well as business aviation, it is mandatory that the DO-178 certification is completed for every airborne software, abiding by the objectives specified in this regulation.
What is DO-178C?
For any kind of airborne vehicles, whether commercial or military jets, compliance with functional safety standards is a must. One such Functional safety standard is DO-178C. Updated from the former DO-178B, DO-178C is a standard, every aerospace organization must comply with to receive the certificate of being flight-worthy.
This standard ensures that the airplane’s systems are secure enough as it travels from one location to another. Thus, DO-178C compliance is crucial, as it takes care of the crew as well as the passengers’ safety on air.
A break-up of objectives for software lifecycle processes
DO-178C was released in the year 2012 and it sets out certain objectives for 10 processes and activities involved in the lifecycle of avionics software. Meeting these each of these objectives can be varyingly challenging.
The number of objectives defined by the DO-178C standard for the different processes are:
- 7 objectives for software planning
- 7 objectives for software development
- 7 objectives for software requirements
- 13 objectives for software design
- 9 objectives for software coding and integration
- 5 objectives for integration
- 9 objectives for verification
- 6 objectives for configuration management
- 7 objectives for software development
- 5 objectives for quality assurance
- 3 objectives for certification liaison
Safety levels under DO-178C.
There are five safety levels, A to E, classified by DO-178C. Each level indicates the consequence in the occasion of software failure. The levels and their corresponding impacts are as follows:
1. Level A — Catastrophic failure
2. Level B — Hazardous failure
3. Level C — Major failure
4. Level D — Minor failure
5. Level E — No effect (non-operative)
The safety levels indicate the amount of risk involved. Wherein, levels A to C are the most serious and involves the lives of passengers and crew. Therefore, these levels require meeting more safety objectives as compared to lesser significant impacts in levels D and E.
Achieving the DO-178C Compliance — Best Practices Checklist
Since DO-178C certification is mandatory to consider yourself worthy of flying safely, there are certain parameters that you must consider for achieving the compliance certificate successfully. The below checklist can help:
1. Have a robust process documentation.
The primary focus of DO-178C is to build robust software processes for ensuring safety. So, having a solid, system-level document-supported RE processes to feed your software process is essential. Here, the goal is to showcase to the certification authorities that you have adhered to their standards by standardizing repeatable procedures.
Your process of requirements analysis must be documented in such a way that it depicts a wholesome picture of the overall process and provides an apt description of every single step. Here, the steps must be explained based on the entry & exit criteria, tools used during your analysis, procedures and reports or data that are required to be presented.
2. Demonstrate traceability.
For DO-178 compliance, properly define your design processes and software requirements to showcase traceability. This traceability should be such that the low-level software requirements should trace to high-level requirements, while high-level requirements trace to the system, so on and so forth.
Along with demonstrating the traceability, you should also be able to explain how you plan to do it. This explanation includes deciding on what tool/tools are being used to demonstrate traceability.
3. Define evaluation criteria.
To maintain consistency in requirements, you must define your parameters for evaluating the requirements. These parameters need to include guidelines for using imperatives such as will, shall, should and must — which of these words are permitted and its meaning and the context where it can be used.
Additionally, you also need to specify the criteria for the placement and the form of distinct identifiers in all your requirement statements. Furthermore, to prevent any ambiguity, you must highlight which words should be avoided or used with caution.
4. Verify & quantify the requirements.
The functional requirements must be expressed in terms of a specific system’s input and output. Since both inputs & outputs are quantities, it becomes easy to quantify and verify them. This kind of “black box” approach uses testing & other verification methods, thereby allowing developers a free hand to design the software as they deem fit.
As per the requirements in the DO-178C guidelines, tolerances must also be specified wherever necessary. These tolerances are not just limited to the input & output quantities, but it is also applicable to the system reaction times because it is the latter that keeps an account of the data transmission times as well as latencies.
5. Ensure consistency in units & terms.
To objectively verify the requirements, it is essential that all the units and terms present in the requirements should be unequivocally specified. It is important for stakeholders to mutually understand every term in the specifications and the measurement units used in the requirement expressions.
To enforce consistency, preparing and updating a glossary of all the project-related technical terms is essential. For better visibility, these glossary items must be arranged by quantity, such as mass, velocity, volume, etc. Furthermore, all your requirements must be checked to see make sure that these units and terms are used as specified.
6. Avoid specifying implementation details.
Software developers and testers need some level of freedom to design software that is best suited for the project.
If you specify every implementation detail of how an algorithm should function, there would be too much cluttering in the system requirements. As a result, problems pertaining to verification may arise as the checking system response cannot properly verify these details.
7. Segregate rationale from the requirement statement.
While explaining the rationale behind derived requirements, it is important to remember that such an explanation or rationale doesn’t misrepresent what the requirements say.
Any kind of detraction can confuse both the developers as well as the system designers. To ensure that no such thing happens, it is advisable to separate all explanatory texts from the stated requirements distinctly.
8. Automate the process of requirements analysis.
Doing a manual analysis of the requirements is a long and time-consuming process. With the growing complexity and size of airborne software, its problems have become way more complicated. Moreover, the requirements are written in natural language, which is why its two-step analysis process becomes labor-intensive and impacts the project’s schedule as well as budget.
Fortunately, some open-source natural language processing (NLP) tools available can come in handy to automate the requirement analysis process. These tools generate reports, which are to be used as process fulfillment artifacts, thereby streamlining the schedule and freeing engineers from manually doing this tedious task.
9. Eliminate conflicts among requirements sets.
Being consistent with the requirements is essential to move forward in a project smoothly. However, when diverse stakeholders provide many requirements, which are to be developed & augmented, the chances of conflicts among the requirements are obvious. These conflicts need to be identified and eliminated so that they do not clog up a project but doing this can be a real task.
A requirements analysis tool can greatly simplify the process by comparing various requirements with similar wording. Post comparison, they can easily identify the exact requirements and remove them. This reduces the degree of similarity and helps you find the correct requirements and eliminate the conflicting ones.
10. Cycle the derived requirements.
Depending on which process you are working in, derived requirements of the high-level software can be described by software developers, systems engineers, or both. Irrespective of the case, the guidelines of DO-178C necessitate that these derived requirements are “provided to the systems processes,” which includes both the requirements analysis process as well as the system safety assessment process.
In layman’s terms, you need to apply your documented process of requirements analysis to all the high-level software requirements that you have defined.
Final thoughts
Adhering to all these best practices would ensure that get a DO-178C compliance certificate successfully. However, keeping in mind the criticality of the software used in airborne systems, seeking assistance from industry leaders in aviation software testing is advisable.
Most industries in the aviation sector do not want to take any chance with safety. Further, the shift-left approach of software testing service providers ensures that your project schedule and delivery are perfectly on track.
