ISO 26262 Functional Safety: Tools and Compliance Evidence

ISO 26262 is the international standard for the functional safety of electrical and electronic systems in road vehicles. It does not tell you which tools to buy. It tells you which obligations apply at your ASIL, which methods it recommends, and which evidence you must be able to put in front of an assessor. It also places the argument that your tools are fit for their job on you rather than on your vendors.

This page sets out what the 2018 edition actually says about software development and software tooling, cites the clause or table behind every normative claim, and then shows where the tools GSAS carries produce evidence against those specific obligations. Where a rating or a sub-clause number could not be confirmed against the standard’s own text, it is left out rather than guessed.

What the standard covers

The scope of the current edition, stated in ISO 26262-6:2018, Clause 1, is:

This document is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production road vehicles, excluding mopeds.

The 3,500 kg gross-weight limit that still circulates widely in secondary material belongs to the withdrawn 2011 first edition, not to the standard in force. The Foreword of ISO 26262-6:2018 records that this edition cancels and replaces the ISO 26262:2011 series, and lists among its main changes requirements for trucks, buses, trailers and semi-trailers, requirements for motorcycles, guidance for semiconductors, and guidance on fault tolerance, safety related special characteristics and software tools.

The standard’s own account of its lineage, from the Introduction to ISO 26262-6:2018, is:

The ISO 26262 series of standards is the adaptation of IEC 61508 series of standards to address the sector specific needs of electrical and/or electronic (E/E) systems within road vehicles.

That relationship matters commercially. Teams already working to IEC 61508 in industrial or energy programmes are working from the parent framework, not a different one.

The twelve parts

Parts 1 to 9 are listed as normative references in ISO 26262-6:2018, Clause 2, with the titles below. Parts 10 to 12 are the guideline and adaptation parts.

Part	Title
1	Vocabulary
2	Management of functional safety
3	Concept phase
4	Product development at the system level
5	Product development at the hardware level
6	Product development at the software level
7	Production, operation, service and decommissioning
8	Supporting processes
9	Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses
10	Guidelines on ISO 26262
11	Guidelines on application of ISO 26262 to semiconductors
12	Adaptation of ISO 26262 for motorcycles

For software teams the operative parts are Part 6, product development at the software level, and Part 8, supporting processes, whose Clause 11 governs confidence in the use of software tools. ISO 26262-6:2018, 4.5 confirms that for motorcycle items the requirements of Part 12 supersede the corresponding requirements of Part 6.

What an ASIL is, and what it is not

ISO 26262-1:2018, 3.6 defines the automotive safety integrity level as:

one of four levels to specify the item’s or element’s necessary ISO 26262 requirements and safety measures to apply for avoiding an unreasonable risk, with D representing the most stringent and A the least stringent level.

Note 1 to that entry is short and frequently ignored: QM is not an ASIL. QM is the outcome when no ISO 26262 safety requirement follows from the analysis, not a fifth rung on the ladder.

The ASIL is assigned by the hazard analysis and risk assessment in ISO 26262-3:2018, Clause 6. Hazardous events are classified in 6.4.3 by severity, probability of exposure and controllability, and safety goals are determined in 6.4.4. Part 3 also carries an informative Annex B on hazard analysis and risk assessment.

Because the ASIL is an output of that analysis for a specific item in a specific vehicle, it is not a permanent property of a category of ECU. Tables that assert “airbag control is ASIL D, infotainment is QM” are rules of thumb from vendor marketing, not citations, and they are omitted here for that reason.

ASIL decomposition

ISO 26262-1:2018, 3.3 defines ASIL decomposition as:

apportioning of redundant safety requirements to elements, with sufficient independence, conducing to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements.

Two of its notes constrain how far the relief goes. Note 2 to entry states that ASIL decomposition does not apply to random hardware failure requirements. Note 3 to entry states that reducing the ASIL of the redundant safety requirements has exclusions, and gives confirmation measures, which remain at the level of the safety goal.

ISO 26262-6:2018, 4.4 sets the applicability rule for software: the requirements and recommendations of each sub-clause refer to the ASIL of the safety goal, and if ASIL decomposition has been performed at an earlier stage in accordance with ISO 26262-9:2018, Clause 5, the ASIL resulting from the decomposition shall be met.

How to read an ISO 26262 method table

This is the single most misquoted part of the standard, so it is worth stating before any table appears. ISO 26262-6:2018, 4.3 (with identical wording at ISO 26262-3:2018, 4.3) defines the rating symbols:

”++” indicates that the method is highly recommended for the identified ASIL; ”+” indicates that the method is recommended for the identified ASIL; and “o” indicates that the method has no recommendation for or against its usage for the identified ASIL.

There is no symbol for “mandatory” and no symbol for “required”. The strongest rating the standard applies to a method is highly recommended.

4.3 also distinguishes consecutive entries, marked by a plain sequence number, from alternative entries, marked by a number followed by a letter such as 1a, 1b, 1c. For alternative entries:

For alternative entries, an appropriate combination of methods shall be applied in accordance with the ASIL indicated, independent of whether they are listed in the table or not. If methods are listed with different degrees of recommendation for an ASIL, the methods with the higher recommendation should be preferred. A rationale shall be given that the selected combination of methods or even a selected single method complies with the corresponding requirement.

So the obligation in a lettered-row table is to choose a combination and to justify it. That is why the correct statement about MC/DC at ASIL D is “highly recommended (++), with a rationale required for the combination chosen”, and why “ASIL D mandates MC/DC” is a misreading of 4.3.

The Part 6 obligations that drive tooling

Coding and modelling guidelines: clause 5.4.3 and Table 1

The clause that makes a coding standard an ISO 26262 topic is ISO 26262-6:2018, 5.4.3:

Criteria for suitable modelling, design or programming languages (see 5.4.2) that are not sufficiently addressed by the language itself shall be covered by the corresponding guidelines, or by the development environment, considering the topics listed in Table 1.

The standard then names MISRA itself. EXAMPLE 1 to 5.4.3 reads:

MISRA C (see Reference [3]) is a coding guideline for the programming language C and includes guidance for automatically generated code.

EXAMPLE 2 adds that in model based development with automatic code generation, guidelines can be applied at the model level as well as the code level, and that appropriate modelling style guides including the MISRA AC series can be considered.

Note the table number. The topics are carried by Table 1, “Topics to be covered by modelling and coding guidelines”. Table 4 in the 2018 edition is “Methods for the verification of the software architectural design” and has nothing to do with coding standards, so a citation of “Part 6, Table 4” for coding guidelines is wrong.

Table 1 has nine alternative-entry rows in the 2018 edition:

Row	Topic	ASIL A	ASIL B	ASIL C	ASIL D
1a	Enforcement of low complexity	++	++	++	++
1b	Use of language subsets	++	++	++	++
1c	Enforcement of strong typing	++	++	++	++
1d	Use of defensive implementation techniques	+	+	++	++
1e	Use of well-trusted design principles	+	+	++	++
1f	Use of unambiguous graphical representation	+	++	++	++
1g	Use of style guides	+	++	++	++
1h	Use of naming conventions	++	++	++	++
1i	Concurrency aspects	+	+	+	+

Rows 1a, 1b and 1c are the three that a MISRA-checking static analyser addresses directly, and all three are highly recommended at every ASIL including ASIL A. One change worth knowing if you are working from older material: the 2011 edition rated row 1d “o” at ASIL A, where the 2018 edition rates it ”+”.

Software unit verification: Clause 9 and Tables 7, 8 and 9

Clause 9 of ISO 26262-6:2018 is Software unit verification, and 9.4.4 is the requirement that invokes the structural coverage table.

Three tables in Clause 9 bear on tooling.

Table 7, “Methods for software unit verification”, includes row 1h Static code analysis and row 1i Static analyses based on abstract interpretation, alongside row 1j Requirements-based test, 1k Interface test, 1l Fault injection test, 1m Resource usage evaluation and 1n Back-to-back comparison test between model and code.

Table 8, “Methods for deriving test cases for software unit testing”, has four rows: 1a Analysis of requirements, 1b Generation and analysis of equivalence classes, 1c Analysis of boundary values, and 1d Error guessing. The classification tree method is a worked example of row 1b.

Table 9, “Structural coverage metrics at the software unit level”, has exactly three rows, with these ratings:

Row	Metric	ASIL A	ASIL B	ASIL C	ASIL D
1a	Statement coverage	++	++	+	+
1b	Branch coverage	+	++	++	++
1c	MC/DC (modified condition/decision coverage)	+	+	+	++

Three things in that table contradict the version of it that circulates most widely.

Statement coverage is highly recommended at ASIL A and B and then drops to recommended at ASIL C and D. It is not an ASIL A only metric. The reason it relaxes rather than disappears is definitional: ISO 26262-1:2018, 3.13 defines branch coverage as the percentage of branches of the control flow executed during a test, and its Note 1 to entry records that 100 % branch coverage implies 100 % statement coverage. Once branch coverage is the stronger recommendation, statement coverage is subsumed by it.

Branch coverage is already recommended at ASIL A, not introduced at ASIL B.

MC/DC is recommended at ASIL A, B and C, and highly recommended only at ASIL D. Combined with the alternative-entry rule in 4.3, that means an ASIL D project must apply an appropriate combination of these metrics and give a rationale for the combination it selected. It does not mean MC/DC is mandated.

Structural coverage at the architectural level: Table 12

ISO 26262-6:2018, Table 12, “Structural coverage at the software architectural level”, uses function coverage and call coverage. MC/DC is not an architectural-level metric in ISO 26262, and a coverage strategy that promises MC/DC at the architectural level has misread which table it is working from.

The full Part 6 table index

So that no table on this site or in a project plan has to be guessed at, these are the tables of ISO 26262-6:2018:

Table	Title
1	Topics to be covered by modelling and coding guidelines
2	Notations for software architectural design
3	Principles for software architectural design
4	Methods for the verification of the software architectural design
5	Notations for software unit design
6	Design principles for software unit design and implementation
7	Methods for software unit verification
8	Methods for deriving test cases for software unit testing
9	Structural coverage metrics at the software unit level
10	Methods for verification of software integration
11	Methods for deriving test cases for software integration testing
12	Structural coverage at the software architectural level
13	Test environments for conducting the software testing
14	Methods for tests of the embedded software
15	Methods for deriving test cases for the test of the embedded software
C.1	Mechanisms for the detection of unintended changes of data

Only the ASIL ratings for Table 1 and Table 9 are reproduced on this page. The method names for the other tables are well attested in public engineering literature, but their rating columns are not, so publishing them here would be guesswork. Bring the licensed copy of Part 6 to any planning discussion that depends on them.

Confidence in the use of software tools: Part 8, Clause 11

ISO 26262-8:2018, Clause 11 is titled Confidence in the use of software tools. Its sub-clauses are 11.4.1 General requirement, 11.4.2 Validity of predetermined Tool Confidence Level or qualification, 11.4.3 Software tool compliance with its evaluation criteria or its qualification, 11.4.4 Planning of usage of a software tool, 11.4.5 Evaluation of a software tool by analysis, 11.4.6 Qualification of a software tool, 11.4.7 Increased confidence from use, 11.4.8 Evaluation of the tool development process, 11.4.9 Validation of the software tool, and 11.5 Work products.

Tool impact (TI)

Tool impact, defined in ISO 26262-8:2018, 11.4.5, expresses the possibility that a malfunction of a particular software tool can introduce or fail to detect errors in a safety-related item or element being developed.

• TI1 is selected when there is an argument that there is no such possibility.
• TI2 is selected in all other cases.

The direction matters, and it is commonly published backwards. TI1 is the benign classification. Because a compiler translates the safety-related source into the object code that ships, a compiler is the archetypal TI2 tool: there is normally no credible argument that it cannot introduce an error.

Tool error detection (TD)

Tool error detection, also in 11.4.5, expresses the confidence that relevant tool malfunctions producing erroneous output will be prevented or detected, whether by tool-internal measures or by tool-external measures such as subsequent process activities.

• TD1: high degree of confidence that a malfunction and its corresponding erroneous output will be prevented or detected.
• TD2: medium degree of confidence.
• TD3: all other cases.

Tool confidence level (TCL)

ISO 26262-8:2018, Table 3, “Determination of the tool confidence level”, is invoked from 11.4.5 and combines the two:

	TD1	TD2	TD3
TI1	TCL1	TCL1	TCL1
TI2	TCL1	TCL2	TCL3

A TI1 tool is TCL1 whatever its detection rating. A TI2 tool earns TCL1 only when detection confidence is high, and falls to TCL2 and then TCL3 as detection confidence weakens.

TCL1 requires no qualification measures at all. For TCL2 and TCL3, an appropriate combination of qualification methods is selected from ISO 26262-8:2018, Tables 4 and 5 according to the TCL and the target ASIL. The four methods are the clause titles themselves: increased confidence from use (11.4.7), evaluation of the tool development process (11.4.8), development in compliance with a safety standard, and validation of the software tool (11.4.9).

TCL belongs to a use case, not to a product

This is the rule that most vendor marketing gets wrong, including marketing that has appeared on this site in the past. The classification depends on the tool functionalities actually used, inside a specific development process. The resulting TCL can be reduced by improving detection or avoidance measures elsewhere in that process, and a process change such as removing a redundant downstream tool can invalidate the TCL argument that was previously made.

It follows that no vendor and no partner can tell you that a product “is TCL2” or “is TCL3”. Only you can classify your use of it. Any supplier who quotes you a TCL for a product, without reference to your process, is selling you something the standard does not recognise.

Responsibility does not transfer with the certificate either. As the ZVEI best practice guideline puts it, summarising Clause 11:

This approach can be supported by the tool vendor, e.g. by providing information such as generic analyses based on intended application use cases or test cases and test suites for tool qualification. The responsibility for using the tool in a suitable way remains with the user.

The two Clause 11 work products

The work products are the software tool criteria evaluation report (ISO 26262-8:2018, 11.5.1) and the software tool qualification report (11.5.2). Part 6 cross-references both at 5.4.1, NOTE 2:

The software tool criteria evaluation report (see ISO 26262-8:2018, 11.5.1) or the software tool qualification report (see ISO 26262-8:2018, 11.5.2) can provide input to the tool usage.

ISO 26262-6:2018, 5.3.2 also lists “qualified software tools available (see ISO 26262-8:2018, Clause 11)” as further supporting information for the software development phase. A vendor kit is an input to your tool usage argument. It is not the argument.

Where the GSAS toolchain produces evidence

GSAS Micro Systems is an engineering partner, not a certificate vendor. What follows maps tools GSAS actually carries to named ISO 26262 obligations, with the vendor’s own certification wording attributed to the vendor, and with no claim that buying a tool discharges an obligation that the standard assigns to you.

1. Coding guidelines and static analysis

Obligations: ISO 26262-6:2018, 5.4.3 and Table 1, in particular rows 1a enforcement of low complexity, 1b use of language subsets and 1c enforcement of strong typing, all rated ”++” at every ASIL. Also Table 7, row 1h, static code analysis, under Clause 9 software unit verification.

Perforce Helix QAC is a static code analyser for C and C++. Perforce states in its own datasheet that “Helix QAC is certified for safety related software development by TÜV-SÜD, for functional safety standards including IEC 61508, ISO 26262, EN 50128, IEC 60880, and IEC 62304”, with the supported levels footnoted as ISO 26262 up to ASIL level D, IEC 61508 up to SIL 4, EN 50128 up to SW-SIL 4 and IEC 62304 up to Software Safety Class C. Perforce lists MISRA C:2023, MISRA C:2012 including AMD4, MISRA C++:2023, MISRA C++:2008 and AUTOSAR C++14 among its supported coding standards.

A note on naming, because the confusion is common and has appeared on this site before: QA-C is the legacy PRQA name for Helix QAC. They are one product with two generations of branding, not two products you would evaluate side by side.

Perforce Klocwork is the second Perforce static analysis engine GSAS carries, oriented toward defect detection and secure coding alongside standards compliance. Perforce states that Klocwork is TUV-SUD certified for ISO 26262 up to ASIL D, IEC 61508 up to SIL 4, EN 50716 up to SW-SIL 4 and IEC 62304 up to Software Safety Class C.

For the coding-standard side of this work in detail, see the MISRA and AUTOSAR compliance page.

2. Dynamic verification and structural coverage

Obligations: ISO 26262-6:2018, Clause 9 software unit verification, with Table 7 (verification methods), Table 8 (test case derivation) and Table 9 (structural coverage metrics, 9.4.4).

Razorcat TESSY is a unit and integration test environment. Per Hitex, “TESSY is qualified to be used in safety-related software development according to IEC 61508, ISO 26262, EN 50128, and IEC 62304”. TUV SUD issued the certificate initially in December 2011 and renews it regularly, and the Tool Qualification Package documents the TESSY functionality to be validated, the validation activities and the test results. TESSY measures entry point coverage, statement coverage, branch coverage, decision coverage, MC/DC and multiple condition coverage, which spans every row of Table 9 and then some.

Two deliberate omissions. Neither Razorcat nor Hitex attaches an ASIL level to TESSY, so this page does not invent one, and the certificate document itself references ISO 26262-8:2011. Whether a report is accepted is an assessor’s decision about your evidence, not a property GSAS or Razorcat can promise in advance.

Razorcat CTE, the Classification Tree Editor sits upstream of test execution and addresses Table 8 row 1b, generation and analysis of equivalence classes, by making the equivalence-class structure of a test specification explicit and reviewable rather than implicit in a spreadsheet.

3. Compiler and library confidence

Obligations: ISO 26262-8:2018, Clause 11. The compiler and the C/C++ standard library sit directly on the path from safety-related source to shipped object code, which makes them TI2 tools in almost every realistic process.

There are two honest routes here, and GSAS supports both.

Route A, buy the qualified toolchain. Arm Compiler for Embedded FuSa is the safety-qualified variant, not standard Arm Compiler 6. Per Arm, qualified AC6 FuSa releases are TUV SUD certified to ISO 26262 ASIL D, IEC 61508 SIL 3, railway software at SIL 4 and IEC 62304 Class C, and are delivered with a Qualification Kit containing the TUV SUD certificate, a Safety Manual, a Test Report, a Defect Report and a Development Process Report. Arm FuSa RTS extends the same approach to the Cortex-M runtime system. Certification applies to specific qualified releases, so the release you plan to certify against is a question to settle before procurement, not after.

Route B, generate your own evidence. Most Indian ECU programmes are not on a vendor-qualified compiler. They are on GCC, on Clang, or on a silicon-vendor toolchain that ships no qualification kit at all, and for those teams Route A does not exist at any price. Solid Sands sells this as two separate catalogue items and the difference matters when you raise a purchase order. SuperTest, the Compiler Test and Validation Suite, is the test corpus itself: per Solid Sands it is “the test and validation suite for C and C++ compilers and libraries that has tracked the (ISO) language specifications for more than 40 years”. The SuperTest Qualification Suite is the separate product that turns a test run into a tool-confidence argument. Solid Sands frames the problem on that product’s page exactly as the standard does: “Functional safety standards like ISO 26262 for the automotive industry require that adequate confidence and quality levels are demonstrated for software tools.” Per the same page, the Qualification Suite establishes compiler confidence by passing a large number of hand-crafted tests, providing high compiler code coverage, comparing results with reference values, exhaustively testing use-case specific constructs and features, passing custom tests such as regression tests, and accurately determining and reconstructing test runs so the evidence is reproducible. This maps to ISO 26262-8:2018, 11.4.9, validation of the software tool.

Solid Sands SuperGuard extends the same treatment to the C and C++ standard library, which is the layer teams most often discover late that they cannot justify.

Route B is the part of this portfolio that most Indian automotive teams do not know exists, and it is usually the one that unblocks a programme whose silicon choice has already been made.

4. Safety-certified RTOS

SEGGER embOS-Safe is the certification-oriented edition of embOS. Per SEGGER, embOS-Safe is certified by TUV SUD, with certification evidence for IEC 61508 SIL 3, IEC 62304 Class C and ISO 26262 ASIL D, and the package includes the certificate itself and a comprehensive safety manual. ISO 26262 ASIL D is stated by SEGGER directly, so no “mappable from SIL 3” argument is needed or offered.

5. On-target verification hardware

SEGGER J-Link probes are how unit and integration tests get executed on the real ECU target rather than only on a host simulation, which matters for the resource usage and timing behaviour that host runs cannot represent. No functional safety certification claim is attached to J-Link, and none is implied here.

Summary map

ISO 26262 obligation	Clause or table	GSAS tool	What it produces
Coding and modelling guidelines	Part 6, 5.4.3 and Table 1 (1a, 1b, 1c)	Helix QAC, Klocwork	MISRA and AUTOSAR compliance reports, deviation records, complexity metrics
Static code analysis in unit verification	Part 6, Table 7 row 1h	Helix QAC, Klocwork	Defect and rule-violation findings traceable to units
Test case derivation	Part 6, Table 8 row 1b	Razorcat CTE	Explicit equivalence-class test specifications
Software unit verification and structural coverage	Part 6, Clause 9, 9.4.4, Tables 7, 8 and 9	Razorcat TESSY	Statement, branch, decision, MC/DC and MCC coverage with test results
Confidence in a purchased compiler	Part 8, Clause 11	Arm Compiler for Embedded FuSa, Arm FuSa RTS	Vendor Qualification Kit as input to your 11.4 argument
Confidence in a compiler with no vendor kit	Part 8, 11.4.9	Solid Sands SuperTest plus the SuperTest Qualification Suite	Reproducible compiler validation evidence you own
Confidence in the C/C++ standard library	Part 8, 11.4.9	Solid Sands SuperGuard	Library qualification evidence
Certified real-time kernel	Part 6 software development environment	SEGGER embOS-Safe	TUV SUD certificate and safety manual per SEGGER
On-target execution of unit and integration tests	Part 6, Clauses 9 and 10	SEGGER J-Link	Test execution on production silicon

What GSAS does not claim

Stating the boundary is more useful to a safety engineer than another paragraph of enthusiasm, so:

• No product “is” TCL2 or TCL3. TCL is assigned by the tool user to a use case inside a specific development process, per ISO 26262-8:2018, 11.4.5.
• A vendor certificate is an input, not a conclusion. Per Clause 11, the responsibility for using the tool in a suitable way remains with the user.
• Nothing in a Part 6 method table is mandatory. Per 4.3, the strongest rating is highly recommended, and lettered rows require you to select a combination and give a rationale.
• Assessor acceptance is not a product feature. No tool vendor and no engineering partner can commit to how your assessor will treat your evidence.
• This page publishes only the ASIL ratings it could verify, namely ISO 26262-6:2018 Tables 1 and 9. Ratings for the other Part 6 tables are omitted rather than approximated.

ISO 26262 engineering support across India

GSAS Micro Systems was founded in 2010 and represents 25 active technology partners. The work described on this page is done with automotive OEM and Tier-1 engineering centres, powertrain and body-control ECU teams, and ADAS programmes, in the sectors where ISO 26262 evidence is a condition of the platform contract rather than an aspiration.

The Pune office is the GSAS Automotive and EV Sector Hub, focused on OEMs and Tier-1 automotive suppliers, and it is the usual starting point for an ISO 26262 toolchain conversation. Bengaluru carries the corporate headquarters, the primary engineering hub and a separate manufacturing facility. Chennai covers the South India automotive and electronics manufacturing corridor. Hyderabad is served by two offices, one in HITEC City for semiconductor and VLSI design support and one at Kapra, Secunderabad for the defence electronics cluster. Delhi NCR, Mumbai, Coimbatore, Visakhapatnam and Vadodara complete a footprint of eleven locations across nine cities, backed by service coverage in a much wider set of industrial centres.

What that presence buys a safety programme is specific: applications engineers who can sit with your team during a tool evaluation, work through a Table 1 or Table 9 gap on your actual codebase, and escalate to partner engineering at Perforce, Razorcat, Arm, Solid Sands or SEGGER when a question outruns the documentation. Procurement and invoicing are the easy part. Local technical depth during qualification is not.

Frequently asked questions

Does ISO 26262 still only apply to vehicles under 3,500 kg?

No. That limit belonged to the 2011 first edition. ISO 26262-6:2018, Clause 1 states that the document is intended to be applied to safety-related E/E systems installed in series production road vehicles, excluding mopeds, and the Foreword lists requirements for trucks, buses, trailers, semi-trailers and motorcycles among the changes introduced by the 2018 edition.

Does ASIL D require MC/DC?

It highly recommends it. In ISO 26262-6:2018, Table 9, MC/DC is rated ”++” at ASIL D and ”+” at ASIL A, B and C. Because Table 9 rows are alternative entries, clause 4.3 requires you to apply an appropriate combination of the listed metrics and to give a rationale that the combination, or even a single selected method, complies with the corresponding requirement. There is no “mandatory” rating anywhere in the standard.

Which ISO 26262 table covers coding standards such as MISRA C?

ISO 26262-6:2018, Table 1, “Topics to be covered by modelling and coding guidelines”, invoked by clause 5.4.3. MISRA C is named in EXAMPLE 1 to that clause. Table 4 is “Methods for the verification of the software architectural design” and is a common miscitation.

Can a tool vendor tell me my Tool Confidence Level?

No. Under ISO 26262-8:2018, 11.4.5, the TCL follows from tool impact and tool error detection for the functionalities you actually use, within your development process, and can change if that process changes. A vendor can supply generic analyses, test suites and qualification evidence as input. The responsibility for using the tool in a suitable way remains with the user.

What is the difference between Helix QAC and QA-C?

There is none. QA-C is the legacy PRQA name for the product Perforce now sells as Helix QAC. Treating them as two products in a tool selection matrix is a naming artefact, not a real choice.

Our project uses GCC, not a certified compiler. What are our options under Part 8?

The compiler is almost always a TI2 tool, so unless your process gives high error-detection confidence you will land at TCL2 or TCL3 and need qualification measures. Two routes are practical. Move to a vendor-qualified toolchain such as Arm Compiler for Embedded FuSa, which ships a Qualification Kit. Or produce the validation evidence yourself with Solid Sands SuperTest and the separately licensed SuperTest Qualification Suite, which together address ISO 26262-8:2018, 11.4.9, validation of the software tool, and add SuperGuard for the C/C++ standard library. GSAS supports both routes.

Is embOS certified for automotive use?

The certification-oriented edition is embOS-Safe. Per SEGGER, it is certified by TUV SUD with certification evidence for IEC 61508 SIL 3, IEC 62304 Class C and ISO 26262 ASIL D, supplied with the certificate and a safety manual.

Talk to GSAS about ISO 26262 evidence

Whether you are scoping a first ASIL programme, closing a structural coverage gap on an existing codebase, or working out how to qualify a compiler that arrived with no kit, the useful conversation starts with your process and your target ASIL, not with a product list.

Talk to a functional safety specialist

---

Related compliance pages: MISRA and AUTOSAR Compliance | IEC 61508 Industrial Safety | DO-178C Airborne Software | UNECE R155 and R156 Cybersecurity

Related solutions: Automotive Solutions | Functional Safety Capabilities