Design Article
DO-178C takes safety-critical software development to the next level
Tim King, DDC-I and Bill StClair, LDRA
4/2/2012 9:08 AM EDT
Tool qualification
Qualification of a tool is needed when processes of DO-178C are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified in the standard. The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.
The Software Tool Qualification Considerations document introduces a new tool qualification structure that consists of three criteria and five Tool Qualification Levels (TQLs) as shown in Table 1.
Criteria 1’s applicable TQL is the replacement for the development tool in DO-178B.
Criteria 2 is new for DO-178C and is intended to address the expansion of tool use in new methodologies. Criteria 2 basically requires an increased level of rigor over DO-178B criteria for tools used on software level A and B in order to increase the confidence in the use of the tool.
Criteria 3, which consists entirely of the level TQL-5, is the replacement for verification tool in DO-178B.
Automated verification tools
A number of companies offer high-level tools that help automate the DO-178C verification process, including two-way traceability. LDRA’s tool set, for example, automates the mapping of requirements in whatever form they’re captured, be it a formal requirements traceability solution, a formal requirements capture solution, or informal documentation (such as Word documents, PDFs, text files, etc.). The tools also provide a core framework for establishing traceability forwards and backwards, from requirements down through the decomposition tree, onto the executable code and back again. Requirements can also be traced to the actual verification tasks that are used to ensure that code meets the minimum standard for the desired certification level.
Automated analysis tools are also available to speed the verification process. Dynamic analysis tools, for example, provide coverage analysis at the statement, decision and MC/DC level. From the code creation perspective, static analysis tools allow you to do code standards enforcement and identify latent defects in your code. These defects (such as variables that are declared but not initialized before use, and array out of bounds) may not come up during testing, but hurt you when the system is in service. Static analysis also provides visibility into the complexity of the code, identifying areas of unnecessary complexity that complicate testing and verification. All of the results from static and dynamic analysis can be brought back into the requirements traceability matrix.
Qualification of a tool is needed when processes of DO-178C are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified in the standard. The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.
The Software Tool Qualification Considerations document introduces a new tool qualification structure that consists of three criteria and five Tool Qualification Levels (TQLs) as shown in Table 1.
Criteria 1’s applicable TQL is the replacement for the development tool in DO-178B.
Criteria 2 is new for DO-178C and is intended to address the expansion of tool use in new methodologies. Criteria 2 basically requires an increased level of rigor over DO-178B criteria for tools used on software level A and B in order to increase the confidence in the use of the tool.
Criteria 3, which consists entirely of the level TQL-5, is the replacement for verification tool in DO-178B.
Automated verification tools
A number of companies offer high-level tools that help automate the DO-178C verification process, including two-way traceability. LDRA’s tool set, for example, automates the mapping of requirements in whatever form they’re captured, be it a formal requirements traceability solution, a formal requirements capture solution, or informal documentation (such as Word documents, PDFs, text files, etc.). The tools also provide a core framework for establishing traceability forwards and backwards, from requirements down through the decomposition tree, onto the executable code and back again. Requirements can also be traced to the actual verification tasks that are used to ensure that code meets the minimum standard for the desired certification level.
Automated analysis tools are also available to speed the verification process. Dynamic analysis tools, for example, provide coverage analysis at the statement, decision and MC/DC level. From the code creation perspective, static analysis tools allow you to do code standards enforcement and identify latent defects in your code. These defects (such as variables that are declared but not initialized before use, and array out of bounds) may not come up during testing, but hurt you when the system is in service. Static analysis also provides visibility into the complexity of the code, identifying areas of unnecessary complexity that complicate testing and verification. All of the results from static and dynamic analysis can be brought back into the requirements traceability matrix.
|
|
|
|
|
Navigate to related information