DO-178C Airborne Software Certification: Aerospace Toolchain Solutions

Airborne software reaches a certified aircraft only when the applicant can show a certification authority that a defined set of process objectives has been satisfied, and can produce the life cycle data that proves it. RTCA DO-178C, “Software Considerations in Airborne Systems and Equipment Certification”, dated 13 December 2011, is the document that lists those objectives. The EUROCAE equivalent, ED-12C, is dated January 2012 (FAA AC 20-115D, paragraph 1.b(1)).

GSAS Micro Systems is an India engineering partner for the verification-side tooling that produces that evidence: static analysis against a coding standard, unit and integration testing with structural coverage measurement, compiler and library qualification suites, on-target trace, and requirements-to-test traceability. Every tool below is mapped to the activity it supports and to the evidence it puts in front of a certification office.

A note on citations. DO-178C, DO-330 and the technology supplements are licensed, copyrighted RTCA documents. GSAS does not publish their objective identifiers, table numbers, row letters, section numbers or objective wording on this site. Everything below states the obligation in substance, either as GSAS engineering guidance in our own words or attributed to a public source. Public sources are treated differently, because they cost nothing to read and nothing to check: FAA advisory circulars and orders and NASA technical memoranda are cited here by paragraph and quoted directly, so every authority-level statement on this page can be verified without licensing anything. Take the substance to your licensed copy and to your certification office. A programme plan built on objective numbers transcribed from a website is a plan resting on somebody else’s typo.

What DO-178C is, and what the FAA actually says about it

DO-178C is guidance, not a regulation. FAA Advisory Circular 20-115D, dated 07/21/2017, states in paragraph 1.a that it “describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment in type certification or TSO authorization”, and that the AC “is not mandatory and does not constitute a regulation. However, if you use the means described in the AC, you must follow it in all applicable respects.” Paragraph 6 confirms that ED-12C/DO-178C “is an acceptable means of compliance for the software aspects of type certification or TSO authorization”. AC 20-115D cancels AC 20-115C, dated 19 July 2013 (paragraph 3).

The AC is deliberately aligned with its European counterpart. Paragraph 4.b states that its technical content “is as far as practicable harmonized with European Aviation Safety Agency (EASA) AMC 20-115D, equally based on ED-12C/DO-178C.” That is the only authority-level harmonisation statement this page asserts. GSAS makes no claim about how any other national regulator treats DO-178C, because no published source supports one.

Practically, the guidance takes three forms (AC 20-115D paragraph 4.a): objectives for the software life cycle processes, activities that provide a means of satisfying them, and descriptions of the evidence indicating an objective has been satisfied. A DO-178C programme is therefore an evidence-production exercise, and tool selection is an evidence-production decision.

Continuing under DO-178B, and the Level D exception

AC 20-115D paragraph 5.a allows applicants with established DO-178B processes to keep using them for new development if six criteria are met, among them that the processes have no known deficiencies such as those found in audits or open process-related problem reports, that they were previously used on a certified product at a software level at least as high as the one now being developed, that there are no significant changes to the processes or development environment, and that the applicant does not intend to declare the proposed software as having satisfied DO-178C. If those criteria are not met, paragraph 5.b says to upgrade and develop the new software using DO-178C. Applicants establishing new life cycle processes should do so under DO-178C (paragraph 5.c).

One asymmetry is worth planning for. Under AC 20-115D paragraph 6.c, “Design Description and Source Code are not part of the type design data for Level D.”

The document family: supplements versus supporting documents

AC 20-115D paragraph 1.b recognises five RTCA documents, all dated 13 December 2011, with EUROCAE equivalents dated January 2012. Document numbers and titles are published catalogue metadata, not licensed content, so they can be listed here in full:

Document	Title	EUROCAE equivalent
DO-178C	Software Considerations in Airborne Systems and Equipment Certification	ED-12C
DO-330	Software Tool Qualification Considerations	ED-215
DO-331	Model-Based Development and Verification Supplement to DO-178C and DO-278A	ED-218
DO-332	Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A	ED-217
DO-333	Formal Methods Supplement to DO-178C and DO-278A	ED-216

DO-248C, “Supporting Information for DO-178C and DO-278A” (ED-94C), is categorised separately. AC 20-115D paragraph 1.c identifies it as a supporting document containing “a collection of frequently asked questions (FAQs) and discussion papers (DPs) compiled and approved by the authors of ED-12C and DO-178C to provide clarification of the guidance”. It is not a supplement, and treating it as one in a PSAC is a recurring planning error.

The supplements are not free-standing. AC 20-115D paragraph 8.a is explicit: “You cannot use supplements as stand-alone documents.” When one or more is used, paragraph 8.a(1) requires the Plan for Software Aspects of Certification (PSAC) to describe how DO-178C and the supplement or supplements will be applied together, how the applicable DO-178C objectives and those added or modified by the supplements will be addressed, “which objectives from which documents apply to which software components”, and how the planned activities will satisfy all applicable objectives. Paragraph 6.a makes the arithmetic consequence clear: an applicant using a supplement satisfies the DO-178C objectives and, where applicable, the objectives the supplement adds. Each supplement brings its own objective set on top of the DO-178C set, so a PSAC that promises “DO-178C plus DO-331” is promising more objectives than DO-178C alone, not a substitution.

Design assurance levels

Software level follows from the failure condition the software can contribute to, as classified by the system safety assessment. The FAA’s severity definitions in AC 23.1309-1E, dated 11/17/2011, paragraph 8 “Definitions”, subparagraph x “Failure conditions”, items (1) to (5), are the reference wording:

Level	Failure condition	FAA definition (AC 23.1309-1E)
A	Catastrophic	”expected to result in multiple fatalities of the occupants, or incapacitation or fatal injury to a flight crewmember normally with the loss of the airplane”
B	Hazardous	”a large reduction in safety margins or functional capabilities”, flight crew “cannot be relied upon to perform their tasks accurately or completely”, or “serious or fatal injury to an occupant other than the flight crew”
C	Major	”a significant reduction in safety margins or functional capabilities”, with “a significant increase in crew workload or in conditions impairing crew efficiency”
D	Minor	”a slight reduction in safety margins or functional capabilities, a slight increase in crew workload … or some physical discomfort to passengers or cabin crew”
E	No safety effect	”would have no effect on safety (that is, failure conditions that would not affect the operational capability of the airplane or increase crew workload)”

The number of DO-178C objectives that apply falls as the level descends, and software classified as having no safety effect carries none at all. That makes the level assignment the most consequential number in the whole programme, and it is a system safety assessment output rather than a software decision. GSAS does not publish per-level objective counts, because the only authoritative source for them is the licensed standard.

DO-178C also raises the requirement for independence as the level rises: certain objectives must be satisfied by a person or process other than the one that produced the item under review. Independence is a property of who performs the activity, not of which tool is used, and no tool discharges it. GSAS does not publish per-level independence counts either, for the same reason.

Which activities the standard expects, and which get confused

DO-178C organises its objectives by life cycle process: planning, development, verification of the requirements outputs, verification of the design outputs, verification of the coding and integration outputs, testing of the integration outputs, verification of the verification results, configuration management, quality assurance, and certification liaison. Three of those are routinely confused with one another in project plans, and the confusion is expensive because it puts tool evidence in the wrong place.

Configuration management is not quality assurance. Problem reporting, change control, change review and configuration status accounting are configuration management activities, alongside identifying configuration items, establishing baselines and traceability, archive and retrieval and release, software load control, and control of the software life cycle environment. A tool that provides issue tracking and change control should be planned against configuration management, not against quality assurance.

Quality assurance is an assurance activity, not a verification one. Its objectives are all of the same shape: obtaining assurance that the plans and standards were developed and reviewed, that the life cycle processes complied with those approved plans and standards, that the transition criteria between processes were met, and that a software conformity review was conducted. These are satisfied by people and records. A tool can make the records retrievable and the transition criteria auditable; it cannot obtain the assurance for you.

Certification liaison is a third, separate process, covering communication and understanding between the applicant and the certification authority, agreement on the proposed means of compliance through the PSAC, and compliance substantiation. AC 20-115D paragraph 6.a ties it directly to FAA involvement: if the FAA chooses not to be involved in the certification liaison process, the applicant can treat those objectives and activities as satisfied once the certification liaison life cycle data has been produced.

Two activities anchor most of the tooling on this page. Coding-standard conformance analysis, showing that the source code conforms to the software code standards, sits in the verification of the coding and integration outputs. On-target compatibility, showing that the executable object code is compatible with the target computer, sits in the testing of the integration outputs. Neither needs a table coordinate to be planned correctly; both need a named tool, a configuration and a record.

Stage of involvement reviews

FAA Order 8110.49 Chg 1 sets out what each Stage of Involvement (SOI) review examines. Read in tooling terms rather than in the Order’s own objective coordinates, it comes out like this:

Review	What it examines
SOI 1, Software Planning Review (paragraph 2-4.c)	The planning process in full, the configuration management planning, the review of plans and standards, and the establishment of certification liaison and the means of compliance
SOI 2, Software Development Review (paragraph 2-5.c)	The development process and the verification of the requirements, design, coding and integration outputs, including coding-standard conformance, plus the configuration management, quality assurance and certification liaison activities that must already be running
SOI 3, Software Verification Review (paragraph 2-6.c)	Testing of the integration outputs and the verification of the verification results, including structural coverage, plus configuration management in full and certification liaison in full

Reading that backwards is the fastest way to work out when tool evidence has to exist. Coding-standard analysis has to be configured, baselined and producing deviation records by SOI 2. Structural coverage results, test procedures and problem reporting records are read at SOI 3. A programme that buys a coverage tool after SOI 2 has already bought it late.

Verification obligations: structural coverage by software level

The structural coverage criteria are graded by software level. Per the NASA and FAA practical tutorial on Modified Condition/Decision Coverage (NASA/TM-2001-210876, May 2001), statement coverage applies down to Level C, decision coverage at Levels A and B, and MC/DC at Level A alone. DO-178C carries that mapping forward unchanged.

Alongside the code-structure criteria, the standard expects analysis of data coupling and control coupling, which in GSAS’s reading applies at Levels A, B and C, on the same footing as statement coverage rather than only at the top two levels.

Three consequences follow, and each is a place where published summaries commonly go wrong. Level D has no structural coverage obligation at all. Data coupling and control coupling analysis reaches down to Level C, not only to A and B. And decision coverage is not a Level C expectation: Level C asks for statement coverage plus data and control coupling, which is a materially cheaper verification campaign than a plan written defensively against decision coverage.

The same verification-of-verification process carries objectives that have nothing to do with code structure: that test procedures are correct, that test results are correct with any discrepancies explained, and that testing covers the high-level requirements and the low-level requirements. Those are the reason a unit test tool has to do requirements traceability as well as coverage measurement. A coverage number with no requirement behind it satisfies none of them.

MC/DC, and why it drives verification effort at Level A

MC/DC requires that each condition in a decision be shown to independently affect that decision’s outcome. NASA/TM-2001-210876 section 2.3.5 states that “the independence requirement ensures that the effect of each condition is tested relative to the other conditions” and that achieving MC/DC requires “in general, a minimum of n+1 test cases for a decision with n inputs”. The alternative, multiple condition coverage, “requires exhaustive testing of the input combinations to a decision” and is impractical for decisions of any width. MC/DC is the compromise that makes Level A structural coverage tractable, and it is still the most test-case-hungry criterion in the set. Our coverage guide works through what each metric does and does not prove.

DO-178C also added a Level A obligation that DO-178B did not carry in its objective set: verification of additional code that the compiler, linker or other tools generate and that cannot be traced back to source code. DO-178B expected the applicant to address traceability between source code and object code, but no corresponding objective sat alongside the structural coverage objectives. DO-178C clarifies two things: structural coverage analysis may be performed at source code, object code or executable object code level, with the applicant choosing the most appropriate level, and where the toolchain emits code sequences that are not directly traceable to source, Level A requires additional verification of them.

Tool qualification: the DO-178C criteria and DO-330

DO-178C defines three tool qualification criteria and maps criterion plus software level onto one of five tool qualification levels. AC 20-115D paragraph 10.c(1) describes the arrangement: “ED-12C/DO-178C establishes five levels of tool qualification based on the tool use and its potential impact in the software life cycle processes.”

Criterion 1 subsumes what DO-178B called development tools. Criteria 2 and 3 split the former verification tools according to the certification credit claimed. Criterion 3 is the classic verification-tool case: the tool produces or verifies an artifact and the credit claimed is limited to the objectives applicable to that artifact. Criterion 2 is where the credit claimed extends beyond the data the tool directly verifies.

The mapping onto tool qualification levels, stated in substance rather than reproduced as the standard’s grid, works out as follows. A Criterion 1 tool tracks the software level: TQL-1 at Level A, then TQL-2, TQL-3 and TQL-4 as the level descends. A Criterion 2 tool is TQL-4 at Levels A and B and TQL-5 at Levels C and D. A Criterion 3 tool is TQL-5 at every software level, including Level A. That last row is the one content on this topic most often gets wrong, and getting it wrong is what turns a routine static analysis purchase into an imagined qualification programme. The same correlation appears in AC 20-115D Table 2, a public FAA table that maps DO-178B tool qualification types onto the DO-178C criteria and TQLs, so it can be checked without licensing the standard.

The published worked examples of Criterion 3 are directly relevant to the tools on this page: a tool that produces test procedures from test cases, where the certification credit is limited to the correctness of those test procedures, and “a code checker that verifies the compliance of source code to the coding standard”, where the credit is limited to the coding-standard conformance objective.

The step up from TQL-5 to TQL-4 is a real one. TQL-4 requires Tool Requirements data describing all functionality implemented in the tool, additional detail about the tool architecture, and verification that the tool complies with those Tool Requirements. Where that data is deficient, an applicant may still use the tool and qualify it at TQL-5, with credit limited to the verification objectives of the data under verification. For commercial off-the-shelf tools whose supplier does not provide the full life cycle data, DO-330 allows the applicant to augment the vendor’s data to satisfy the objectives for the applicable TQL.

Tool criteria are the applicant’s determination, not a vendor attribute

This deserves emphasis, because tool criteria are sometimes presented as a fixed property of a product. They are not. AC 20-115D paragraph 10.a directs the applicant to apply the DO-178C tool qualification criteria to determine whether qualification is needed at all and, if it is, to “use the software level assigned by the system safety assessment for determining the required Tool Qualification Level (TQL), and use ED-215/DO-330 for the applicable objectives, activities, and life cycle data.” Paragraph 10 adds that DO-330 “contains its own complete set of objectives, activities, and life cycle data for tool qualification”.

DO-330 is a domain-independent document; DO-178C is the domain standard that references it, defines the criteria, and selects the TQL. No supplier, GSAS included, can classify a tool as Criterion 1, 2 or 3 on your behalf, and no tool ships pre-classified. What a supplier can do is supply the tool, supply whatever qualification material the OEM publishes, and support the applicant’s own qualification activity.

The GSAS toolchain, mapped to the activities

Coding-standard conformance analysis

Perforce Helix QAC and Perforce Klocwork automate coding-standard conformance analysis, the activity behind the source-code-conforms-to-standards objective. Perforce states that QAC provides “comprehensive coverage of coding, safety, and security-focused standards, including MISRA, AUTOSAR, CERT, WP.29, ISO 26262, and DO-178C with the QAC DO-330 Tool Qualification pack”, and that “QAC helps you achieve certification for DO-178C and DO-278 faster, using the DO-330 Qualification Pack”. Of Klocwork, Perforce states that it “helps enforce strict coding standards so you can achieve certification faster for DO-178C, ensuring the safety of your airborne systems”; Klocwork analyses C, C++, C#, Rust, Java, JavaScript, Python and Kotlin. Both statements are Perforce’s, and are quoted as such.

Two boundaries should be set explicitly in the PSAC. First, the TUV SUD certificates these tools carry are scoped to industrial, automotive, railway and medical standards, not to DO-178C. QAC’s certificate covers IEC 61508-3:2010, ISO 26262-8:2018, EN 50716:2023, IEC 62304:2015 and IEC 60880; Klocwork’s covers IEC 61508-3:2010, ISO 26262-8:2018, EN 50128:2011/A2:2020 and IEC 62304. The DO-178C route for QAC is the separate DO-330 Tool Qualification Pack Perforce publishes, not the TUV certificate. A certificate is scoped to the standards named on it, and no assessor treats an automotive tool certificate as airborne evidence. The ISO 26262 page records what each Perforce certificate actually says. Second, and more usefully, a code checker whose certification credit is limited to coding-standard conformance is the published example of a Criterion 3 tool, which is TQL-5 at every software level. Planning that correctly is cheaper than planning it defensively.

Requirements-based testing and structural coverage

Razorcat TESSY executes requirements-based unit, integration and system tests for embedded C and C++ on host and target, and measures the coverage criteria the structural coverage objectives name. Razorcat lists TESSY’s coverage measurements as statement coverage (C0), branch coverage (C1), decision coverage (DC), modified condition/decision coverage (MC/DC), multiple condition coverage (MCC), entry point coverage, function coverage and call pair coverage. On the requirements side, TESSY imports requirements via ReqIF from DOORS, Jama Connect and Visure, from Polarion via a plug-in, or as CSV and XML, exports requirement and validation results to XML and ReqIF, and links test cases back to requirements so that requirements coverage and change impact can be analysed in both directions. That covers both halves of the verification-of-verification obligation: test coverage of the high-level and low-level requirements, and structural coverage of the code up to MC/DC.

State the certification position accurately. TUV SUD certificate Z10 078930 0004 Rev. 01, issued 2023-11-15 and valid until 2028-11-12, records that TESSY “fulfills the requirements for support tools classified T2 according to IEC 61508-3 and EN 50128”, is “qualified to be used in safety-related software development according to IEC 61508, EN 50128 and ISO 26262”, and is “suitably validated for use in safety-related development according to IEC 62304”. It was tested against IEC 61508-3:2010, IEC 62304:2006 with AMD1:2015, ISO 26262-8:2018 and EN 50128:2011/A2:2020. DO-178C and DO-330 are not within that certificate’s scope. Qualifying TESSY, or any verification tool, for a DO-178C programme is the applicant’s activity under DO-330, against the criterion the applicant selects and the software level the system safety assessment assigns.

Tool-chain trust: the compiler and the runtime library

This is the part of the GSAS catalogue with the clearest published DO-178C position, and it covers tool-chain elements that are easy to leave out of an initial plan. Solid Sands heads its aerospace page “Software component qualification you can trust for RTCA DO-178C and EUROCAE ED-12C” and states that “for qualification and verification of the tool chain, in which the compiler that translates source code into executable code is an essential component, RTCA DO-178C / EUROCAE ED-12C refers to supplemental standard DO-330 / ED-215 ‘Software Tool Qualification Considerations’.” That supplemental standard, Solid Sands continues, “requires avionic system developers to demonstrate that each element in the tool chain does not introduce errors that could escape detection by subsequent verification activities.”

Solid Sands SuperTest supplies that demonstration for C and C++ compilers. Per Solid Sands, SuperTest “contains requirements-based tests to validate that the compiler correctly implements source language constructs, negative tests to check that it flags invalid code, and stress tests to see how it behaves with boundary-pushing code”, plus differential testing across compiler versions and “traceability features that link clauses in the language standard with individual tests”. Traceability from a language-standard clause to the test that exercises it is exactly the shape of evidence a tool qualification argument needs.

The library case is separate and easy to miss. Solid Sands notes that although standard libraries are often shipped inside the compiler’s SDK, “invoked library code becomes part of the safety-critical executable code”, and that “in avionic applications, libraries therefore fall under the requirements of the DO-178C / ED-12C software considerations standard and require independent verification with a library safety qualification suite such as SuperGuard.” Code that links into the executable is airborne software, whoever wrote it.

Execution on the target computer

Showing that the executable object code is compatible with the target computer means requirements-based tests running on real hardware rather than a host simulation, with enough observability to prove what executed. SEGGER J-Trace provides unlimited streaming trace: SEGGER describes it as recording “complete instruction traces over unlimited periods of time”, with Live Code Coverage and Live Code Profiling, and “instruction-level code coverage to satisfy regulatory requirements”. SEGGER Ozone adds “integrated performance analysis tools, including instruction trace, code profiling, and code coverage” on the debugger side.

Two clarifications, both because accuracy here is cheap and inaccuracy is expensive. Streaming trace and live code coverage are J-Trace capabilities; J-Link PRO, which SEGGER describes as “the ultra-fast debug probe with USB and Ethernet interfaces”, is a debug and flash programming probe and this page attributes no instruction-trace capability to it. And neither J-Trace nor Ozone carries any DO-178C or DO-330 qualification claim from SEGGER; they are instruments that help you observe and evidence on-target execution, not certified artifacts.

Traceability, problem reporting and configuration data

Problem reporting, change control, change review and configuration status accounting, along with baselines and traceability, are the configuration management side of the evidence. Perforce Helix ALM addresses it: Perforce describes it as capturing and tracking requirements, managing test cases and test runs, tracing tests and issues back to requirements, and generating traceability matrices without manual assembly, because “requirements, test cases, and issues are linked, so traceability happens automatically”. Used alongside TESSY’s ReqIF links, it closes the loop from a high-level requirement through a test case to a problem report and back.

Quality assurance is a different matter, and no tool discharges it. Its objectives are satisfied by people and records, as set out above.

One scoping note, since Perforce publishes a broad product line: Helix ALM is the Perforce product GSAS supplies for requirements, test and issue traceability. GSAS does not carry Perforce Helix Core, and configuration and version control tooling is outside the toolchain described on this page.

What GSAS does not claim

• No tool “is” Criterion 1, 2 or 3, and no tool ships pre-classified. The criterion follows from how you use the tool and what certification credit you claim, and the TQL follows from that criterion and the software level the system safety assessment assigns. AC 20-115D paragraph 10.a puts that determination on the applicant.
• A vendor qualification pack is an input, not the argument. Where an OEM publishes one, as Perforce does for QAC, it feeds your DO-330 activity. It does not replace it.
• A certificate is scoped to the standards named on it. The TUV SUD certificates behind Helix QAC, Klocwork and TESSY name industrial, automotive, railway and medical standards. None of them names DO-178C or DO-330.
• Assessor and certification office acceptance is not a product feature. No tool vendor and no engineering partner can commit to how your certification office will treat your evidence.
• This page does not reproduce the standard. DO-178C and DO-330 are licensed, copyrighted documents. Their objective identifiers, table numbers, row letters and section numbers are not published here. License what you need and read it.

Why engineering teams in India work with GSAS on DO-178C tooling

GSAS is an engineering partner, not a certification consultancy, and the distinction is worth being direct about. The applicant owns the PSAC, the tool qualification criterion, the TQL selection and the compliance substantiation. What GSAS brings is the tooling and the local engineering to make those tools productive.

1. Tool-chain trust, sourced from the only GSAS-carried vendor with a published DO-178C position. Solid Sands SuperTest and SuperGuard address compiler and standard-library verification, the tool-chain elements DO-178C hands to DO-330 and that most programmes discover late.
2. Verification-side depth against the right activities. Helix QAC and Klocwork for coding-standard conformance analysis; TESSY for requirements-based testing and structural coverage, up to MC/DC and multiple condition coverage.
3. Qualification material quoted, not embellished. Where an OEM publishes a DO-330 pack, as Perforce does for QAC, GSAS says so and attributes it. Where a certificate is scoped to IEC 61508, ISO 26262, EN 50128 or IEC 62304 rather than DO-178C, as with TESSY and Klocwork, GSAS says that too.
4. On-target evidence. J-Trace streaming trace and live code coverage, with Ozone for trace visualisation, profiling and coverage, for requirements-based testing on the real target computer.
5. Traceability that survives an audit. Helix ALM for requirements-to-test-to-issue linkage on the configuration management side of the evidence.
6. 25 active technology partners and direct OEM relationships, which means current versions, escalation paths and licence support rather than intermediated sourcing.
7. Local application engineering. Licensing, INR procurement, installation, build-system integration, training and FAE support delivered by engineers in the same time zone as your programme.

GSAS supports aerospace and defence electronics teams from offices in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR and Visakhapatnam, alongside sites in Coimbatore and Vadodara. The customer base for this toolchain is sectoral rather than named: aircraft OEMs and their supply chains, avionics and line-replaceable unit suppliers, engine and APU control suppliers, Tier-1 and Tier-2 aerospace suppliers, and engineering services firms building airborne software for programmes whose certification basis is set under FAA AC 20-115D or its EASA counterpart AMC 20-115D. Evaluation licences, build-system integration, tool training and ongoing FAE support for every tool on this page are available from Bengaluru, Hyderabad, Chennai, Pune and the other GSAS locations listed above.

Frequently asked questions

What is the difference between DO-178B and DO-178C?

DO-178C, dated 13 December 2011, superseded DO-178B, and DO-178C summarises the differences in its own appendix (AC 20-115D paragraph 4.a). The most consequential structural change is that tool qualification moved out into DO-330, a domain-independent document with its own complete set of objectives, activities and life cycle data. Three technology supplements were added: DO-331 for model-based development and verification, DO-332 for object-oriented technology and related techniques, and DO-333 for formal methods. DO-178C also added objectives covering parameter data item files, which did not exist in DO-178B, and a Level A objective covering verification of additional code that cannot be traced back to source code. It clarified that structural coverage analysis may be performed at source code, object code or executable object code level, at the applicant’s choice.

Which structural coverage criteria apply at each level?

Per the NASA and FAA tutorial on MC/DC, statement coverage applies down to Level C, decision coverage at Levels A and B, and MC/DC at Level A alone, a mapping DO-178C carries forward unchanged. Data coupling and control coupling analysis applies at Levels A, B and C. Level D has no structural coverage obligation, and software classified as having no safety effect carries no DO-178C objectives at all.

Do problem reporting and change control belong to quality assurance?

No. Problem reporting, change control, change review and configuration status accounting are configuration management activities. Quality assurance is a separate process, and its objectives are all about obtaining assurance that the plans and standards were developed and reviewed, that the processes complied with them, that transition criteria were met and that a conformity review was conducted. Certification liaison is a third process again, covering communication with the authority, agreement on the means of compliance and compliance substantiation. Planning a change-control tool against quality assurance is a common way to arrive at SOI 3 with the evidence filed under the wrong process.

What TQL does a static analysis tool need?

That is the applicant’s determination, not the tool vendor’s. AC 20-115D paragraph 10.a directs the applicant to apply the DO-178C tool qualification criteria and then use the software level assigned by the system safety assessment to determine the required TQL. The published worked example is helpful, though: a code checker that verifies compliance of source code to the coding standard, with certification credit limited to coding-standard conformance, is a Criterion 3 tool, and a Criterion 3 tool is TQL-5 at every software level. If the credit claimed extends beyond the data the tool directly verifies, the tool falls under Criterion 2, which is TQL-4 at Levels A and B and TQL-5 at Levels C and D.

Can I use a COTS tool if the vendor does not supply full qualification data?

DO-330 anticipates this. Where tool life cycle data is insufficient to qualify at TQL-4, an applicant may still use the tool and qualify it at TQL-5, with certification credit limited to the verification objectives of the data under verification. For commercial off-the-shelf tools, DO-330 allows the applicant to augment the supplier’s data to satisfy the objectives for the applicable TQL.

Does GSAS supply tools for DO-278A ground-based systems?

Tool qualification for DO-278A uses the same document as DO-178C: the three supplements are titled as supplements “to DO-178C and DO-278A” (AC 20-115D paragraph 1.b), and DO-330 is the shared tool qualification document. Published DO-330 guidance treats AL1 and AL2 for DO-278A users as the counterparts of software levels A and B when applying the tool qualification criteria. GSAS makes no claim about the full DO-278A assurance-level scale, and the tools on this page carry no DO-278A qualification claim beyond what Perforce publishes for QAC.

When does tool evidence have to be ready?

FAA Order 8110.49 Chg 1 sets the review scope. Coding-standard conformance is examined at the SOI 2 software development review, so static analysis configuration, baseline and deviation handling need to be settled by then. Structural coverage results, test procedures and problem reporting records are read at the SOI 3 software verification review. Planning documents, the establishment of configuration management, the review of plans and standards, and the opening of certification liaison are examined at SOI 1.

Get started with DO-178C tooling

Whether you are planning a first Level C programme, adding MC/DC measurement for a Level A component, or closing the tool-chain gap around your compiler and standard library, GSAS can supply the tools, the licences and the local application engineering to get them producing evidence against the right objectives.

Talk to a GSAS applications engineer

Bring your software level, your target and your current tool chain, and we will map them to the activities on this page.

---

Sources for this page: FAA AC 20-115D (07/21/2017); FAA AC 23.1309-1E (11/17/2011); FAA Order 8110.49 Chg 1; NASA/TM-2001-210876; TUV SUD Product Service certificate Z10 078930 0004 Rev. 01 (TESSY) and the QAC and Klocwork certificate scopes recorded on the ISO 26262 page; the AdaCore DO-330/ED-215 and DO-178C/ED-12C papers; and the Perforce, Razorcat, Solid Sands and SEGGER product pages cited inline. Statements about what DO-178C and DO-330 require are GSAS engineering guidance in our own words. The normative text is in the licensed standards and is not reproduced here.

---

Related compliance pages: ISO 26262 Automotive Safety | IEC 61508 Industrial Safety | MISRA and AUTOSAR Compliance

Related solutions: Aerospace and Defence Solutions | Functional Safety Capabilities