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, in plain engineering terms, what the 2018 edition asks of software development and software tooling, and then shows where the tools GSAS carries produce evidence against those obligations. Two constraints shape how it is written. Vendor claims are attributed to the vendor, and certificate claims are attributed to the certificate, because those are not the same thing. And ISO 26262 is a licensed, copyrighted document, so this page does not reproduce its clause numbers, its method tables, its row letters or its rating grids. You get the substance, stated as GSAS engineering guidance or attributed to a public source. For the normative wording, read your licensed copy of the part concerned. Where something could not be sourced to a document you can check, it is left out rather than guessed.

What the standard covers

The 2018 edition applies to safety-related systems that include one or more electrical or electronic (E/E) systems installed in series production road vehicles, excluding mopeds. ISO publishes the title and scope of every part in its public catalogue, so you can confirm the boundary before you license anything.

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 2018 edition cancelled and replaced the 2011 series, extended it to trucks, buses, trailers, semi-trailers and motorcycles, added guidance for semiconductors, and added guidance on fault tolerance, safety related special characteristics and software tools. If a supplier tells you ISO 26262 does not reach your commercial vehicle platform because it is over 3.5 tonnes, they are quoting a standard that was withdrawn eight years ago.

ISO 26262 is the road-vehicle adaptation of the IEC 61508 series. 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, and much of the process evidence transfers.

The twelve parts

Part titles are published metadata, not licensed content, so they can be listed here in full. Parts 1 to 9 are the normative parts. 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, which is where confidence in the use of software tools is dealt with. For motorcycle items, Part 12 supersedes the corresponding Part 6 requirements, so a two-wheeler programme that plans straight off Part 6 is planning against the wrong part.

What an ASIL is, and what it is not

An ASIL is one of four levels, A through D, that specifies which ISO 26262 requirements and safety measures apply in order to avoid an unreasonable risk, with D the most stringent and A the least.

QM is not an ASIL. QM is the outcome when the analysis produces no ISO 26262 safety requirement at all. It is not a fifth rung below A. This distinction is in the standard’s own definition and it is routinely skipped, which matters because a QM classification is a conclusion that the standard’s requirements do not apply to that element, not a lenient grade of compliance you can talk your way into.

The ASIL is assigned by the hazard analysis and risk assessment (HARA) in Part 3, which classifies each hazardous event by severity, probability of exposure and controllability, and determines safety goals from that classification.

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 results of anyone’s HARA, and they are omitted here for that reason.

ASIL decomposition

ASIL decomposition apportions redundant safety requirements to elements with sufficient independence, all conducing to the same safety goal, so as to reduce the ASIL that applies to each of those redundant requirements.

Two limits follow directly from that definition and constrain how far the relief actually goes. Decomposition does not apply to random hardware failure requirements. And the reduction has exclusions: confirmation measures remain at the level of the safety goal rather than dropping to the decomposed level. A decomposition argument that quietly relaxes the rigour of the confirmation review has not decomposed anything, it has just moved the problem.

For software, Part 6 sets the applicability rule. The requirements and recommendations refer to the ASIL of the safety goal, and where decomposition has already been performed in accordance with Part 9, the ASIL resulting from that decomposition is the one to be met.

How to read the standard’s recommendations

This is the single most misquoted aspect of the standard, so it is worth settling before any obligation is discussed. Part 3 and Part 6 both rate methods with three symbols. ”++” means the method is highly recommended for the identified ASIL. ”+” means it is recommended. “o” means there is no recommendation for or against its use at that ASIL.

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

The standard also separates consecutive entries from alternative entries. Where entries are alternatives, the obligation is not to apply all of them. It is to apply an appropriate combination in accordance with the ASIL, whether or not every method in that combination appears in the standard’s own list; to prefer the more strongly recommended methods where the recommendations differ; and to give a rationale that the combination selected, or even a single selected method, complies with the requirement.

So the correct statement about MC/DC at ASIL D is “highly recommended, with a rationale required for the combination chosen”. “ASIL D mandates MC/DC” is a misreading, and an assessor who has read the standard will treat it as one.

A note on citations. GSAS does not publish the standard’s clause numbers, table numbers, row letters or rating grids on this site. They are the copyrighted content of a document you have to license, and a project plan built on numbers transcribed from a website rather than read from the licensed text is a plan resting on somebody else’s typo. Everything below states the obligation in substance. Take it to your licensed copy and to your assessor.

The Part 6 obligations that drive tooling

Coding and modelling guidelines

The obligation that makes a coding standard an ISO 26262 topic is straightforward. Whatever criteria for a suitable modelling, design or programming language the language itself does not sufficiently address must be covered by guidelines, or by the development environment. C addresses very few of them by itself, which is the whole reason a coding standard is in scope at all.

The standard does not mandate any particular coding standard. It does use MISRA C as its worked example of a coding guideline for C, including for automatically generated code, and it points at model-level style guides, the MISRA AC series among them, for model based development with automatic code generation. In practice that means MISRA C or MISRA C++, plus AUTOSAR C++14 where a project is on that ruleset, is the route almost every Indian ECU programme takes.

The topics the standard expects those guidelines to cover are, in GSAS’s summary: enforcement of low complexity, use of language subsets, enforcement of strong typing, use of defensive implementation techniques, use of well-trusted design principles, use of unambiguous graphical representation, use of style guides, use of naming conventions, and concurrency aspects. The recommendation strength attached to each is not uniform across the four ASILs, and the licensed text is where you read which is which.

The first three are the ones a MISRA-checking static analyser addresses head on, and all three carry the standard’s strongest recommendation at every ASIL, ASIL A included. That is the practical point most often missed in an evaluation: there is no ASIL at which a language-subset argument becomes optional. An ASIL A programme that skips static analysis is not taking a discount the standard offers.

One trap worth naming even without naming a table. The coding-guideline obligation and the software-architectural-design verification obligation are separate obligations in separate clauses with separate method lists. Project plans that cite one and deliver evidence for the other are common, and they fail review.

Software unit verification and structural coverage

Part 6’s software unit verification clause is where static analysis, test-case derivation and structural coverage all land, and it is the clause that most directly drives a tool budget.

Verification methods. Static code analysis and static analysis based on abstract interpretation both appear among the recommended unit verification methods, alongside requirements-based test, interface test, fault injection test, resource usage evaluation, and back-to-back comparison test between model and code. Static analysis is not a nice-to-have bolted on beside unit testing; it is one of the listed verification methods in its own right.

Deriving test cases. Four methods: analysis of requirements, generation and analysis of equivalence classes, analysis of boundary values, and error guessing. The classification tree method is the standard’s own worked example of the equivalence-class route, which is why a classification tree tool has a specific place in this clause rather than being a general convenience.

Structural coverage at the unit level. Three metrics: statement coverage, branch coverage, and MC/DC. Three things about how their recommendations move across the ASILs contradict the version of this that circulates most widely, and all three cost real money when a project gets them wrong.

Statement coverage does not vanish at high ASIL. Its recommendation actually relaxes from the lower ASILs to the higher ones, and the reason is definitional rather than a softening of rigour: 100 % branch coverage implies 100 % statement coverage, so once branch coverage carries the stronger recommendation, statement coverage is subsumed by it. A team reporting branch coverage has already reported statement coverage, whether or not it says so.

Branch coverage is already recommended at ASIL A. It is not introduced at ASIL B, and a plan that defers any branch coverage measurement until an ASIL B feature arrives is deferring something that was recommended from the start.

MC/DC is recommended across the range and carries the strongest recommendation only at ASIL D. Combined with the alternative-entry rule above, that means an ASIL D project applies an appropriate combination of these metrics and gives a rationale for the combination it selected. It does not mean MC/DC is mandated, and it does not mean statement and branch coverage stop mattering once you reach D.

Structural coverage at the architectural level is a different question with different metrics: function coverage and call coverage. MC/DC is not an architectural-level metric in ISO 26262. A coverage strategy that promises MC/DC at the architectural level has conflated the two levels, and that confusion usually surfaces late, as a tooling requirement nobody can actually satisfy.

Confidence in the use of software tools (Part 8)

Part 8, supporting processes, is where ISO 26262 deals with the tools used to build safety-related software. Its treatment runs from a general requirement, through the validity of a predetermined tool confidence level or an existing qualification, compliance of a tool with its evaluation criteria, planning of tool usage, evaluation of a tool by analysis, and qualification of a tool, to the qualification methods themselves and the resulting work products.

The mechanism is worth understanding before any vendor conversation, because vendors routinely describe it backwards.

Tool impact (TI)

Tool impact 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 applies when there is an argument that there is no such possibility.
• TI2 applies 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 expresses the confidence that relevant tool malfunctions producing erroneous output will be prevented or detected, whether by measures inside the tool or by measures outside it such as subsequent process activities.

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

Tool confidence level (TCL)

The two combine into a tool confidence level of TCL1, TCL2 or TCL3. In substance: a TI1 tool is TCL1 whatever its detection rating, because a tool that cannot introduce or mask an error needs no further confidence argument. A TI2 tool reaches TCL1 only where detection confidence is high, sits at TCL2 where detection confidence is medium, and falls to TCL3 in the remaining cases.

TCL1 requires no qualification measures at all. That is the most valuable sentence in the whole mechanism, and it is the one most often absent from a vendor pitch, because it is the outcome that sells nothing.

For TCL2 and TCL3, an appropriate combination of qualification methods is selected according to the TCL and the target ASIL. There are four: increased confidence from use, evaluation of the tool development process, development in compliance with a safety standard, and validation of the software tool.

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 a TCL argument that was previously sound.

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 the tool confidence requirements:

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 work products

Part 8 produces two work products from this activity: the software tool criteria evaluation report and the software tool qualification report. Part 6 points at both of them as inputs to the software development environment, and lists the availability of qualified software tools among the supporting information for the software development phase.

Read that word. Input. A vendor qualification kit is an input to your tool usage argument. It is not the argument. The argument is yours, it lives in your safety plan, and it is assessed against your process.

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 the standard assigns to you.

1. Coding guidelines and static analysis

Obligations: Part 6’s coding and modelling guidelines requirement, in particular enforcement of low complexity, use of language subsets and enforcement of strong typing, which carry the standard’s strongest recommendation at every ASIL. Also static code analysis as a listed software unit verification method.

Perforce Helix QAC is a static code analyser for C and C++. Perforce states in its own datasheet that “QAC is certified for safety related software development by TÜV-SÜD, for functional safety standards including IEC 61508, ISO 26262, EN 50716, 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 50716 up to SW-SIL 4 and IEC 62304 up to Software Safety Class C.

The certificate behind that sentence is TUV SUD Product Service certificate No. Z10 112544 0001 Rev. 03, held by Perforce Software UK Ltd. for the product “Software Tool for Safety Related Development”, models Perforce QAC for C with MISRA C, for C++ with MISRA C++ extended, for C++ with MISRA C++:2023 and for C++ with AUTOSAR C++14, dated 2025-08-22 and valid until 2029-09-11. It records the certified tool as classified T2, qualified for use in safety-related software development according to IEC 61508, ISO 26262, EN 50716 and IEC 60880, and suitably validated for use according to IEC 62304, tested against IEC 61508-3:2010, ISO 26262-8:2018, EN 50716:2023, IEC 60880:2006 and IEC 62304:2015, with test report PO96765C a mandatory part of it. It carries no ASIL, no SIL and no software safety class value anywhere. The certificate is the source of the standards list and the T2 classification. Perforce’s datasheet is the source of the levels. Cite whichever you need, but cite the right one.

Earlier Perforce material, quoted on this page in the past, named EN 50128 in place of EN 50716. That wording is superseded, and if you are holding a QAC datasheet that says EN 50128, you are holding an old one. Perforce lists MISRA C:2025, 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. Two documents are in play here and they do not say the same thing, so be precise about which one you put in front of an assessor.

Perforce’s product page states that “Perforce Klocwork is TÜV-SÜD certified for compliance with key functional safety standards”, and lists 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. Every one of those level qualifiers, “up to ASIL D” included, is Perforce’s own statement on its own product page.

The certificate is TUV SUD Product Service certificate No. Z10 108316 0002 Rev. 00, held by Perforce Software Inc. for the product “Software Tool for Safety Related Development”, model Klocwork, dated 2022-08-12 and valid until 2027-08-11. It records the certified tool as classified T2, fulfilling the requirements for support tools according to IEC 61508-3 and EN 50128, qualified for use in safety-related software development according to IEC 61508, ISO 26262 and EN 50128, and suitably validated for use according to IEC 62304, tested against IEC 61508-3:2010, ISO 26262-8:2018, EN 50128:2011/A2:2020, IEC 62304:2006 and IEC 62304:2006/AMD1:2015, with test report KB85025C a mandatory part of it.

That certificate carries no ASIL value, no SIL value and no software safety class value anywhere on it. So the ISO 26262 fact the certificate supports is a narrower one than the product page’s: Klocwork is qualified for use in safety-related software development according to ISO 26262, and was tested against ISO 26262-8:2018. “Up to ASIL D” is the vendor’s characterisation of what that qualification is good for. Both are legitimate things to cite and GSAS cites both, but they are not interchangeable, and an assessor who asks where the ASIL D figure came from will not accept the certificate as the answer.

Two further gaps between the two documents are worth knowing before you rely on either. The certificate does not name EN 50716; it names EN 50128:2011/A2:2020. The BSI catalogue records BS EN 50716:2023 as cancelling and replacing BS EN 50128:2011+A2:2020, which is the supersession set out on the IEC 61508 page, so the product page and the certificate are describing two different railway revisions and only the certificate is evidence. And the Klocwork certificate expires on 2027-08-11, roughly two years before QAC’s.

None of that weakens the automotive argument, which is what this page is about: the certificate names ISO 26262-8:2018 directly, and that is the part of the tool-confidence story an automotive programme actually needs. It does mean that if your programme is a rail programme, or an automotive programme whose assessor also reads the railway scope, you put the certificate in front of your assessor rather than the product page, and you ask GSAS to confirm the current certificate revision and scope with Perforce before you baseline that part of your tool qualification argument. The Klocwork product page carries the same caution, and the DO-178C page records what each Perforce certificate actually covers.

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

2. Dynamic verification and structural coverage

Obligations: Part 6’s software unit verification clause, covering the verification methods themselves, the derivation of unit test cases, and structural coverage at the unit level.

Razorcat TESSY is a unit and integration test environment. Per Razorcat, “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 unit-level structural coverage metric the standard lists and then some.

Two deliberate omissions. Razorcat does not attach an ASIL level to TESSY, so this page does not invent one. And the current certificate, like both Perforce certificates, records a classification and a standards list rather than a level: TUV SUD Product Service certificate No. Z10 078930 0004 Rev. 01, dated 2023-11-15 and valid until 2028-11-12, records TESSY as a support tool classified T2 according to IEC 61508-3 and EN 50128, qualified for safety-related software development according to IEC 61508, EN 50128 and ISO 26262, and suitably validated for use according to IEC 62304, tested against IEC 61508-3:2010, IEC 62304:2006 with AMD1:2015, ISO 26262-8:2018 and EN 50128:2011/A2:2020. 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 the equivalence-class route to deriving test cases, 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: Part 8’s confidence in the use of software tools. 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. That is the validation-of-the-software-tool route through Part 8, produced by you rather than bought from a compiler vendor who does not offer it.

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	Where it sits in the series	GSAS tool	What it produces
Coding and modelling guidelines	Part 6, coding and modelling guidelines	Helix QAC, Klocwork	MISRA and AUTOSAR compliance reports, deviation records, complexity metrics
Static code analysis as a verification method	Part 6, software unit verification	Helix QAC, Klocwork	Defect and rule-violation findings traceable to units
Deriving unit test cases from equivalence classes	Part 6, software unit verification	Razorcat CTE	Explicit equivalence-class test specifications
Unit verification and unit-level structural coverage	Part 6, software unit verification	Razorcat TESSY	Statement, branch, decision, MC/DC and MCC coverage with test results
Confidence in a purchased compiler	Part 8, confidence in the use of software tools	Arm Compiler for Embedded FuSa, Arm FuSa RTS	Vendor Qualification Kit as an input to your tool usage argument
Confidence in a compiler with no vendor kit	Part 8, validation of the software tool	Solid Sands SuperTest plus the SuperTest Qualification Suite	Reproducible compiler validation evidence you own
Confidence in the C/C++ standard library	Part 8, validation of the software tool	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, unit and integration verification	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, under Part 8. A vendor cannot assign it for you.
• A vendor certificate is an input, not a conclusion. The responsibility for using the tool in a suitable way remains with the user.
• A certificate is not a level. The TUV SUD tool certificates behind Helix QAC, Klocwork and TESSY record a T2 classification and a list of standards tested against. Where this site quotes an ASIL, a SIL or a software safety class for one of those tools, that figure comes from the vendor’s published material and is attributed to the vendor, never to the certificate.
• Nothing the standard recommends is mandatory. The strongest rating it applies is highly recommended, and alternative entries require you to select a combination and give a rationale for it.
• 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 does not reproduce the standard. ISO 26262 is a licensed, copyrighted document. Its clause numbers, table numbers, row letters and rating grids are not published here. License the parts you need and read them.

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 a site in HITEC City for semiconductor and VLSI design support and a second at Kapra, Secunderabad for the defence electronics cluster. Delhi NCR, Mumbai, Coimbatore, Visakhapatnam and Vadodara complete a footprint of 11 offices 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 coding-guideline or structural-coverage 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. The 2018 edition applies to safety-related E/E systems installed in series production road vehicles, excluding mopeds, and explicitly extended the series to trucks, buses, trailers, semi-trailers and motorcycles. ISO publishes the scope of each part in its public catalogue, so you can confirm it without licensing the standard.

Does ASIL D require MC/DC?

It highly recommends it. MC/DC carries the standard’s strongest recommendation at ASIL D and a weaker recommendation at ASIL A, B and C. Because the unit-level coverage metrics are alternative entries, you apply an appropriate combination of them and give a rationale that the combination, or even a single selected method, complies with the requirement. There is no “mandatory” rating anywhere in the standard, at any ASIL.

Where does MISRA C fit in ISO 26262?

Under Part 6’s coding and modelling guidelines requirement. The standard does not mandate MISRA. It uses MISRA C as its worked example of a coding guideline for C, including for automatically generated code, and points at model-level style guides such as the MISRA AC series for model based development with automatic code generation. How compliance is actually claimed, and how deviations are recorded, is set out on the MISRA and AUTOSAR compliance page.

Can a tool vendor tell me my Tool Confidence Level?

No. Under Part 8, the TCL follows from tool impact and tool error detection for the functionalities you actually use, within your development process, and it 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.

Does the Klocwork TUV SUD certificate say ASIL D?

No. The certificate (Z10 108316 0002 Rev. 00, valid until 2027-08-11) records Klocwork as classified T2 and qualified for use in safety-related software development according to IEC 61508, ISO 26262 and EN 50128, tested against ISO 26262-8:2018 among others. It carries no ASIL, SIL or software safety class value. “Up to ASIL D” is Perforce’s statement on the Klocwork product page. Cite the certificate for the qualification and the standards, and cite Perforce for the level.

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 give you the validation-of-the-software-tool evidence Part 8 looks for, 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

---

Sources for this page: ISO’s public catalogue entries for the ISO 26262 series; the ZVEI best practice guideline on tool qualification; TUV SUD Product Service certificates Z10 112544 0001 Rev. 03 (Helix QAC), Z10 108316 0002 Rev. 00 (Klocwork) and Z10 078930 0004 Rev. 01 (TESSY); the BSI catalogue entry for BS EN 50716:2023; and the Perforce, Razorcat, Arm, Solid Sands and SEGGER product and datasheet pages cited inline. Statements about what ISO 26262 requires are GSAS engineering guidance in our own words. The normative text is in the licensed standard and is not reproduced here.

---

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