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 the 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 specific DO-178C Annex A objective it supports, and every normative statement on this page carries the table, clause or paragraph number it came from. Table numbers are not decoration in this domain: an objective cited against the wrong Annex A table is the difference between a plan a certification office accepts and one it sends back.

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 paragraph 6.c, section 9.4 of DO-178C specifies the life cycle data related to the type design of the certified product, but “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	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: the applicant satisfies the objectives listed in the DO-178C Annex A tables “and, where applicable, the ED-215/DO-330, ED-216/DO-333, ED-217/DO-332, and ED-218/DO-331 Annex A tables”. Each supplement brings its own tables in addition to the DO-178C set.

Design assurance levels and objective counts

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)	Objectives
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”	71
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”	69
C	Major	”a significant reduction in safety margins or functional capabilities”, with “a significant increase in crew workload or in conditions impairing crew efficiency”	62
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”	26
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)“	0

The objective counts are the DO-178C Annex A totals applicable at each level; 43 of the 71 relate to verification. Level E carries no DO-178C objectives at all.

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, because no reliable second source reproduces them.

Annex A: which table is which

Annex A of DO-178C is titled “PROCESS OBJECTIVES AND OUTPUTS BY SOFTWARE LEVEL” and contains ten tables totalling 71 objectives. Objectives get cited against the wrong table often enough that it is worth setting the structure out in full:

Table	Process	Objectives
A-1	Software Planning Process	7
A-2	Software Development Processes	7
A-3	Verification of Outputs of Software Requirements Process	7
A-4	Verification of Outputs of Software Design Process	13
A-5	Verification of Outputs of Software Coding and Integration Processes	9
A-6	Testing of Outputs of Integration Process	5
A-7	Verification of Verification Process Results	9
A-8	Software Configuration Management Process	6
A-9	Software Quality Assurance Process	5
A-10	Certification Liaison Process	3
	Total	71

Three of these are routinely confused with one another.

Table A-8 is configuration management, not quality assurance. Its six objectives are: configuration items are identified (A-8-1); baselines and traceability are established (A-8-2); problem reporting, change control, change review, and configuration status accounting are established (A-8-3); archive, retrieval, and release are established (A-8-4); software load control is established (A-8-5); software life cycle environment control is established (A-8-6). Problem reporting and change control are Table A-8 Objective 3. They are not a Table A-9 objective, and a tool that provides them should be planned against A-8-3.

Table A-9 is software quality assurance. All five of its objectives take the form “Assurance is obtained that …”: that software plans and standards are developed and reviewed for compliance with the document and for consistency (A-9-1); that life cycle processes comply with approved software plans (A-9-2); that they comply with approved software standards (A-9-3); that transition criteria for the life cycle processes are satisfied (A-9-4); and that a software conformity review is conducted (A-9-5).

Table A-10 is certification liaison, with three objectives: communication and understanding between the applicant and the certification authority is established (A-10-1); the means of compliance is proposed and agreement with the PSAC is obtained (A-10-2); compliance substantiation is provided (A-10-3). AC 20-115D paragraph 6.a ties this table directly to FAA involvement: if the FAA chooses not to be involved in the certification liaison process, the applicant “can consider the certification liaison process objectives and activities to be satisfied after you have produced the life cycle data specified in Table(s) A-10”.

Two more anchors matter for tooling. Table A-5 Objective 4 is “Source Code conforms to standards”, the objective a coding-standard checker addresses. Table A-5 has nine objectives in DO-178C, including two parameter data item objectives, A-5-8 (“Parameter Data Item File is correct and complete”) and A-5-9 (“Verification of Parameter Data Item File is achieved”), that did not exist in DO-178B. Table A-6 Objective 5 is “Executable Object Code is compatible with target computer”, the objective that on-target execution evidence supports.

Stage of involvement reviews, by Annex A table

FAA Order 8110.49 Chg 1 sets out what each Stage of Involvement (SOI) review examines, expressed directly in Annex A table and objective numbers. The Order is written against DO-178B; the table numbering it cites (A-1 through A-10) is unchanged in DO-178C, though DO-178C adds objectives A-5-8, A-5-9 and A-7-9 within those tables.

Review	Annex A objectives evaluated
SOI 1, Software Planning Review (paragraph 2-4.c)	A-1 (all), A-8 (Objectives 1-4), A-9 (Objective 1), A-10 (Objectives 1-2)
SOI 2, Software Development Review (paragraph 2-5.c)	A-2 (Objectives 1-6), A-3 (all), A-4 (all), A-5 (Objectives 1-6), A-8 (Objectives 1-4 and 6), A-9 (Objectives 1-2), A-10 (Objectives 1-2)
SOI 3, Software Verification Review (paragraph 2-6.c)	A-5 (Objective 7), A-6 (all), A-7 (all), A-8 (all), A-9 (Objectives 1-2), A-10 (all)

Reading that table backwards is the fastest way to work out when tool evidence has to exist. Coding-standard analysis (A-5-4) is examined at SOI 2. Structural coverage (A-7) is examined at SOI 3.

Verification obligations: structural coverage by software level

Table A-7 has nine objectives, of which four cover the structure of the code. The applicable criteria are not stated as prose in section 6.4.4; they are read off the Annex A table by software level.

Objective	Criterion	Section	A	B	C	D
A-7-5	Modified condition/decision coverage (MC/DC)	6.4.4.c	Yes
A-7-6	Decision coverage	6.4.4.c	Yes	Yes
A-7-7	Statement coverage	6.4.4.c	Yes	Yes	Yes
A-7-8	Data coupling and control coupling	6.4.4.d	Yes	Yes	Yes
A-7-9	Verification of additional code, that cannot be traced to Source Code		Yes

The remaining Table A-7 objectives are A-7-1 test procedures are correct (6.4.5.b), A-7-2 test results are correct and discrepancies explained (6.4.5.c), A-7-3 test coverage of high-level requirements is achieved (6.4.4.a), and A-7-4 test coverage of low-level requirements is achieved (6.4.4.b).

Three consequences follow, and each is a place where published summaries commonly go wrong. Level D has no structural coverage objectives at all. Data coupling and control coupling analysis is required at Levels A, B and C, not only at A and B. And decision coverage is not a Level C objective; Level C requires statement coverage plus data and control coupling.

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 objective in the table.

Table A-7 Objective 9 is new in DO-178C and applies only at Level A. Under DO-178B, section 6.4.4.2.b expected the applicant to address traceability between Source Code and Object Code, but nothing in the A-7 table reflected it. 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 at Level A, if the compiler, linker or other tools generate additional code sequences not directly traceable to source code, additional verification is required. That is what A-7-9 captures.

Tool qualification: DO-178C section 12.2.2 and DO-330

DO-178C section 12.2.2 defines three tool qualification criteria, and Table 12-1 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 (see section 12.2.2 and Table 12-1 of ED-12C/DO-178C).”

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.

Tool qualification criterion	Level A	Level B	Level C	Level D
Criterion 1	TQL-1	TQL-2	TQL-3	TQL-4
Criterion 2	TQL-4	TQL-4	TQL-5	TQL-5
Criterion 3	TQL-5	TQL-5	TQL-5	TQL-5

The row that content on this topic most often gets wrong is Criterion 3. A Criterion 3 tool is TQL-5 at every software level, including Level A. The same criterion-to-TQL mapping appears in AC 20-115D Table 2, which correlates DO-178B tool qualification types with DO-178C criteria and TQLs: Development at Level A/B/C/D maps to Criterion 1 and TQL-1/2/3/4; Verification at Levels A and B maps to Criterion 2 and TQL-4; Verification at Levels C and D maps to Criterion 2 and TQL-5; and Verification at all levels maps to Criterion 3 and TQL-5.

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 DO-178C/ED-12C objective A7-1 (‘Test procedures are correct’)”, and “a code checker that verifies the compliance of source code to the coding standard; the certification credit is limited to DO-178C/ED-12C objective A5-4 (‘Source code conforms to standards’)”.

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, section 11 of 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 “use the criteria of section 12.2 of ED-12C/DO-178C to determine if tool qualification is needed” 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”, organised in its own tables T-0 through T-10.

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 Annex A

Table A-5 Objective 4: source code conforms to standards

Perforce Helix QAC and Perforce Klocwork automate coding-standard conformance analysis, the activity behind Table A-5 Objective 4. 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. Second, and more usefully, a code checker whose certification credit is limited to A-5-4 is the published example of a Criterion 3 tool, which is TQL-5 at every software level under Table 12-1. Planning that correctly is cheaper than planning it defensively.

Table A-6 and Table A-7: 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 Table A-7 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 maps to Table A-7 Objectives 3 and 4, test coverage of high-level and low-level requirements, alongside the structural objectives A-7-5 through A-7-8.

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.

Table A-6 Objective 5: execution on the target computer

Table A-6 Objective 5 requires that the Executable Object Code be shown compatible with the target computer, which in practice 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.

Tables A-8 and A-9: traceability, problem reporting and configuration data

Table A-8 Objective 3 requires that problem reporting, change control, change review and configuration status accounting be established, and Objective 2 that baselines and traceability be established. Perforce Helix ALM addresses that side of the evidence: 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.

Table A-9’s five quality assurance objectives are process objectives, satisfied by people and records rather than by any tool. A tool can make the records retrievable and the transition criteria auditable; it cannot obtain the assurance for you.

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.

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 objectives. Helix QAC and Klocwork for Table A-5 Objective 4; TESSY for Table A-6 and the Table A-7 coverage objectives, 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 against Table A-8 Objectives 2 and 3.
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 Appendix A section 3 of DO-178C summarises the differences (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 organised in tables T-0 through T-10. 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. Within Annex A, DO-178C added parameter data item objectives A-5-8 and A-5-9, and added Table A-7 Objective 9 covering verification of additional code that cannot be traced to Source Code at Level A. DO-178C also 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?

MC/DC (Table A-7 Objective 5) applies at Level A only. Decision coverage (A-7-6) applies at Levels A and B. Statement coverage (A-7-7) applies at Levels A, B and C. Data coupling and control coupling (A-7-8) applies at Levels A, B and C. Level D has no structural coverage objectives, and Level E has no DO-178C objectives at all.

Is Table A-9 where problem reporting and change control live?

No. Problem reporting, change control, change review and configuration status accounting are Table A-8 Objective 3, in the Software Configuration Management Process table. Table A-9 is the Software Quality Assurance Process table, whose five objectives all take the form “Assurance is obtained that …”. Table A-10 is the Certification Liaison Process table, with three objectives.

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 section 12.2 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 objective A-5-4, is a Criterion 3 tool, and Criterion 3 is TQL-5 at every software level under DO-178C Table 12-1. 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, section 11 of 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 in Annex A terms. Coding-standard conformance (Table A-5 Objectives 1-6) is examined at the SOI 2 software development review, so static analysis configuration, baseline and deviation handling need to be settled by then. Table A-7 in full, and Table A-8 in full, are examined at the SOI 3 software verification review, which is where structural coverage results, test procedures and problem reporting records are read. Planning documents and the objectives A-8-1 through A-8-4, A-9-1 and A-10-1 to A-10-2 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 Annex A 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 objectives on this page.

---

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

Related solutions: Aerospace and Defence Solutions | Functional Safety Capabilities

Sources for the normative statements on this page: FAA AC 20-115D (07/21/2017); FAA AC 23.1309-1E (11/17/2011); FAA Order 8110.49 Chg 1; RTCA DO-178C Annex A; NASA/TM-2001-210876; the AdaCore DO-330/ED-215 and DO-178C/ED-12C papers; and the vendor and certificate documents cited inline.