IEC 61508 Functional Safety: Industrial Safety Compliance Tools

Most IEC 61508 projects that stall in India do not stall on the code. They stall at the moment an assessor asks a simple question about the toolchain: which of these tools is class T1, which is T2, which is T3, and what evidence does each class need. IEC 61508-3:2010, the software part, answers that question in its requirements for support tools, and IEC 61508-4:2010, the definitions part, supplies the T1, T2 and T3 classes it uses. Neither answer has anything to do with buying a certificate.

This page sets out, in plain engineering terms, what the software part of the series asks of a development toolchain, and then shows which of the tools GSAS Micro Systems supports in India produce the evidence each obligation asks for. Where the standard is permissive, we say so. Where the tools we carry stop short of a claim, we say that too.

A note on citations. IEC 61508 is a licensed, copyrighted document. GSAS does not publish its clause numbers, subclause numbers, table numbers, row letters or the graded recommendation tables that rate techniques against each safety integrity level. Everything below states the obligation in substance, either as GSAS engineering guidance in our own words or attributed to a public source. One table on this page carries numbers rather than substance, the SIL target failure measure bands, and it is set down as GSAS engineering guidance in our own words rather than as a reproduction of anything in the standard. Public sources are treated differently, because they cost nothing to read and nothing to check: IEC’s public catalogue entries and abstracts, the BSI catalogue, and vendor certificates, datasheets and safety manuals are cited here directly and quoted where the exact wording matters. Take the substance to your licensed copy and to your assessor. A safety plan built on numbers transcribed from a website rather than read from the licensed text is a plan resting on somebody else’s typo. Where something could not be sourced to a document you can check, it is left out rather than guessed.

What IEC 61508 is, and which part governs software

IEC 61508 is titled “Functional safety of electrical/electronic/programmable electronic safety-related systems”. The current edition of the series is Edition 2.0, dated 2010-04. IEC 61508-3:2010, the software part, was published on 2010-04-30 as Edition 2.0, its status is Valid, and its stability date is 2027 (IEC publication record for IEC 61508-3:2010).

Edition 2.0 cancelled and replaced the first edition published in 1998, and constitutes a technical revision rather than a reprint. Part 3 was prepared by IEC subcommittee 65A (System aspects) of IEC technical committee 65 (Industrial-process measurement, control and automation), and holds the status of a basic safety publication under IEC Guide 104.

The series has seven parts. Part numbers and their published titles are bibliographic metadata, not licensed content, so they can be listed here in full:

Part	Official title
Part 1	General requirements
Part 2	Requirements for electrical/electronic/programmable electronic safety-related systems
Part 3	Software requirements
Part 4	Definitions and abbreviations
Part 5	Examples of methods for the determination of safety integrity levels
Part 6	Guidelines on the application of IEC 61508-2 and IEC 61508-3
Part 7	Overview of techniques and measures

IEC’s own public abstract for Part 3 sets its reach. It “applies to any software forming part of a safety-related system or used to develop a safety-related system within the scope of IEC 61508-1 and IEC 61508-2”, it “provides specific requirements applicable to support tools used to develop and configure a safety-related system”, it “requires that the software safety functions and software systematic capability are specified”, and it “establishes requirements for safety lifecycle phases and activities which shall be applied during the design and development of the safety-related software”.

Which sector standards IEC 61508 itself names

One of the series’ stated objectives is to facilitate the development of product and application sector international standards based on it, and Part 3 names three examples in its bibliography: IEC 61511 (all parts, safety instrumented systems for the process industry sector), IEC 62061 (safety of machinery) and IEC 61800-5-2 (adjustable speed electrical power drive systems, Part 5-2: safety requirements, functional). That is the complete list the standard gives for itself.

Two further relationships are documented outside IEC 61508, by the derived standards or their tool vendors. ISO 26262 declares itself the adaptation of the IEC 61508 series to the sector specific needs of electrical and electronic systems within road vehicles. For railway software, Razorcat states in the TESSY 5.1 Safety Manual that “EN 50128:2011 is an application standard derived from IEC 61508”; note that the BSI record for BS EN 50716:2023 shows it cancels and replaces BS EN 50128:2011+A2:2020 and BS EN 50657:2017+A1:2023, so EN 50716 is the current railway software reference.

A SIL is a target failure measure, and the mode of operation decides which one

IEC 61508 requires the safety integrity requirement for each safety function to be specified as a target failure measure, and to be qualified as either an average probability of a dangerous failure on demand (PFDavg) for low demand mode, or an average frequency of a dangerous failure per hour (PFH) for high demand or continuous mode. A SIL claim that does not say which mode it refers to is incomplete.

The bands themselves are set out below as GSAS engineering guidance in our own words. They rest on no secondary publication, and this page names none for them, because the only version that settles an argument with an assessor is the normative statement in the licensed standard. Read them there before you baseline a target failure measure. They are also not the difficult part of a SIL claim.

SIL	Low demand mode: average probability of a dangerous failure on demand (PFDavg)	High demand or continuous mode: average frequency of a dangerous failure per hour (PFH)
SIL 1	>= 10^-2 to < 10^-1	>= 10^-6 to < 10^-5
SIL 2	>= 10^-3 to < 10^-2	>= 10^-7 to < 10^-6
SIL 3	>= 10^-4 to < 10^-3	>= 10^-8 to < 10^-7
SIL 4	>= 10^-5 to < 10^-4	>= 10^-9 to < 10^-8

Two things around those bands matter more than the numbers themselves. The first is normative. The standard forbids allocating any single safety function in an E/E/PE safety-related system a target safety integrity failure measure lower than the SIL 4 band, which puts the floor at an average probability of a dangerous failure on demand of 10^-5 for low demand mode and an average frequency of a dangerous failure of 10^-9 per hour for high demand or continuous mode. It adds that lower values may be achievable for non-complex systems, but that these limits represent what can be achieved for relatively complex systems such as programmable electronic safety-related systems at the present time. SIL 4 is a floor on the claim, not an aspiration to be exceeded.

The second is what can actually be calculated. The standard is explicit that it will not be possible to predict quantitatively the safety integrity of all aspects of an E/E/PE safety-related system, that qualitative techniques, measures and judgements will have to be used, and that this is particularly true of systematic safety integrity. It confines the arithmetic to the other half: quantified reliability estimation techniques are applied to hardware safety integrity, to assess whether the target has been achieved taking random hardware failures into account. Software work is systematic safety integrity, so everything below on this page belongs to the qualitative half.

One thing IEC 61508 does not do is tell you which SIL your application needs. There is no table in the standard mapping burner management, emergency shutdown or interlocking to a SIL. SIL is an output of a risk analysis, and IEC 61508-5 is the part titled “Examples of methods for the determination of safety integrity levels”.

The V-model is the reference lifecycle, and it is tailorable

Part 3 uses a V-model as its reference figure for software systematic capability and the development lifecycle. It puts the software safety requirements specification, software architecture, software system design, module design and coding on the left arm, and verifies each against module testing, integration testing at module level, integration testing of components, subsystems and programmable electronics, and validation testing on the right arm.

It is a reference, not a mandate. Any software lifecycle model may be used provided all the objectives and requirements of the relevant clause are met. The depth, number and work-size of the V-model phases may be tailored to take account of the safety integrity and the complexity of the project. One condition attaches: any customisation of the software safety lifecycle has to be justified on the basis of functional safety. That condition is new in Edition 2, introduced to make clear that functional safety must still be achieved when an alternative lifecycle is selected.

If your team already runs an iterative or continuous-integration workflow, the standard does not force you off it. It forces you to show that the objectives are still met, and to justify the customisation on the basis of functional safety.

How to read the standard’s recommendations

Part 3 grades techniques and measures against each safety integrity level, using four codes. HR means the technique is highly recommended at that level, and if it is not used, the rationale for not using it should be detailed during safety planning and agreed with the assessor. R means recommended, a lower recommendation than HR. A dash means there is no recommendation for or against use at that level. NR means positively not recommended at that level, and using it also requires a documented rationale agreed with the assessor.

There is no code for “mandatory” and no code for “required”. The strongest rating the standard applies to any technique is highly recommended. The recommendations are not a closed list either: other measures and techniques may be applied so long as the requirements and objectives have been met. That is the sentence most vendor pages omit.

The recommendations come in two sets. The first, normative set is organised by lifecycle topic: the software safety requirements specification; software architecture design; support tools and programming language; detailed design; software module testing and integration; programmable electronics integration of hardware and software; software aspects of system safety validation; modification; software verification; and functional safety assessment. A second, more detailed set expands particular entries in the first: design and coding standards; dynamic analysis and testing; functional and black-box testing; failure analysis; modelling; performance testing; semi-formal methods; static analysis; and modular approach.

That second set was normative in Edition 1 and is informative in Edition 2. The difference matters when an assessor asks how binding a particular entry is, and it is worth settling in safety planning rather than in the assessment.

Everything that follows states the graded recommendation in substance rather than reproducing the grid, for the reason given at the top of this page. Take it to your licensed copy and to your assessor.

Tool classification is your first deliverable

Part 3’s requirements for support tools, including programming languages, sit in the development sequence between software architecture design and detailed design and development, ahead of code implementation, software module testing and software integration testing. The placement is deliberate. You are expected to have settled your toolchain question before you write production code.

The classification itself comes from IEC 61508-4:2010. A software on-line support tool is one that can directly influence the safety-related system during its run time. A software off-line support tool is one that supports a phase of the software development lifecycle and cannot directly influence the safety-related system during its run time. Off-line tools divide into three classes:

Class	What the class covers	The standard’s own examples
T1	Generates no output that can directly or indirectly contribute to the executable code, including data, of the safety-related system	A text editor; a requirements or design support tool with no automatic code generation capability; configuration control tools
T2	Supports the test or verification of the design or executable code, where an error in the tool can fail to reveal a defect but cannot directly create an error in the executable software	A test harness generator; a test coverage measurement tool; a static analysis tool
T3	Generates output that can directly or indirectly contribute to the executable code of the safety-related system	An optimising compiler where the relationship between the source code program and the generated object code is not obvious; a compiler that incorporates an executable run-time package into the executable code

An on-line tool is not classified at all, it is absorbed: the standard requires a software on-line support tool to be considered a software element of the safety-related system itself.

What the standard then requires of each class

One requirement applies to every off-line tool without exception: the selection of the off-line support tools has to be justified. A T1 tool is not exempt from that sentence, it is only exempt from the requirements below it. Treating T1 as “no work required” is the most common misreading we see.

• Documentation, T2 and T3. Every off-line support tool in class T2 or T3 must have a specification or product documentation that clearly defines the behaviour of the tool and any instructions or constraints on its use. The standard is explicit that this specification or product documentation is not the same thing as a safety manual for a compliant item.
• Assessment, T2 and T3. An assessment has to be carried out for T2 and T3 tools to determine the level of reliance placed on them, and the potential failure mechanisms of the tools that may affect the executable software. Where such failure mechanisms are identified, appropriate mitigation measures have to be taken. The mitigations the standard names are avoiding known bugs, restricting use of the tool functionality, checking the tool output, and using diverse tools for the same purpose.
• Conformance evidence, T3. For each T3 tool, evidence has to be available that the tool conforms to its specification or documentation. That evidence may be based on a suitable combination of history of successful use in similar environments and for similar applications, inside your organisation or in others, and of tool validation. The standard adds that the same evidence may also be used for T2 tools in judging the correctness of their results.
• What validation has to record. Where validation is used, the documented results must cover a chronological record of the validation activities; the version of the tool product manual used; the tool functions being validated; the tools and equipment used; the results of the validation, stating either that the software passed or the reasons for failure; the test cases and their results for subsequent analysis; and any discrepancies between expected and actual results.
• Where conformance evidence is unavailable. There have to be effective measures to control failures of the executable safety-related system that result from faults attributable to the tool.

Note what is absent. IEC 61508 has no per-SIL tool-qualification grading comparable to the tool confidence level mechanism in ISO 26262. The obligations above are the same text at SIL 1 and at SIL 4. What changes with SIL is the technique selection in the recommendation tables, not the structure of the tool argument.

Tools live in the configuration baseline

The configuration-management side of the tool requirements is the part most teams discover late. Where T2 and T3 tools generate items in the configuration baseline, configuration management has to record the identification of the tool and its version, the baseline items that tool version was used for, and the way the tool was used, including the tool parameters, options and scripts selected, for each configuration baseline item. Configuration management also has to ensure that only qualified versions of T2 and T3 tools are used, and each new version of an off-line support tool has to be qualified, though the standard allows that qualification to rely on evidence from an earlier version under stated conditions.

Responsibility for conformance with the support-tool requirements can rest with multiple parties, and the division of responsibility has to be documented during safety planning. If your compiler vendor, your RTOS vendor and your integrator each own a slice of the argument, write that division down before the assessment, not during it.

The standard also gives the categories of off-line tool it has in mind, including verification and validation tools such as static code analysers, test coverage monitors, theorem proving assistants and simulators, and transformation or translation tools such as compilers, assemblers, linkers, binders, loaders and code generation tools. Those two categories map almost exactly onto the three obligations below.

Obligation 1: static verification of the source code

The code verification requirement is unconditional. The source code has to be verified by static methods to ensure conformance to the software module design specification, to the required coding standards, and to the validation plan for software aspects of safety. The standard adds that it is the combination of the results of code verification and software module testing that provides assurance that each software module satisfies its associated specification. Static analysis and dynamic testing are not alternatives.

In the graded recommendations, static analysis as a verification activity is recommended at SIL 1 and highly recommended at SIL 2, SIL 3 and SIL 4. The detailed static-analysis entries grade the individual techniques, and the way they move across the levels is where a budget gets decided:

• Control flow analysis and data flow analysis are recommended at SIL 1 and highly recommended from SIL 2 upward.
• Boundary value analysis is recommended at SIL 1 and SIL 2 and highly recommended at SIL 3 and SIL 4.
• Static analysis of run time error behaviour, the abstract-interpretation case, is recommended at SIL 1, SIL 2 and SIL 3 and becomes highly recommended only at SIL 4.
• Checklists, error guessing and worst-case execution time analysis are recommended at every level.

That last movement is worth knowing before you commit a SIL 2 project to an abstract-interpretation budget on the assumption that the standard asks for one.

The coding standard the code is verified against

The standard requires that programming languages for the development of all safety-related software be used according to a suitable programming language coding standard, and it says what that coding standard has to do: specify good programming practice, proscribe unsafe language features such as undefined language features and unstructured designs, promote code understandability, facilitate verification and testing, and specify procedures for source code documentation.

In the detailed design recommendations, the use of design and coding standards is recommended at SIL 1 and highly recommended from SIL 2 upward, defensive programming carries no recommendation at SIL 1, is recommended at SIL 2 and is highly recommended at SIL 3 and SIL 4, and a modular approach is highly recommended at all four levels.

The coding-standard constraints themselves are the graded rule set, and they tighten as the SIL rises:

• Use of a coding standard to reduce the likelihood of errors is highly recommended at every level, SIL 1 included.
• No dynamic objects, no unconditional jumps in programs in higher level languages and no automatic type conversion are recommended at SIL 1 and highly recommended from SIL 2 upward.
• Limited use of interrupts is recommended at SIL 1 and SIL 2 and highly recommended at SIL 3 and SIL 4.
• No dynamic variables, limited use of pointers and limited use of recursion carry no recommendation at SIL 1, are recommended at SIL 2, and are highly recommended at SIL 3 and SIL 4.

The standard carries a carve-out here that is worth reading before a team bans dynamic allocation outright. The constraints on dynamic objects, dynamic variables and pointers do not need to be applied if a compiler is used which ensures either that sufficient memory for all dynamic variables and objects will be allocated before run time, or that a safe state is achieved in the event of a memory allocation error, and which also ensures that response times meet the requirements.

Where MISRA C actually fits

IEC 61508 does not name MISRA, or any other particular coding standard, as the one to use. Like every other statement of substance on this page, that is GSAS engineering guidance in our own words rather than a search result you can be shown, so confirm it in your licensed copy. What the standard requires is a suitable programming language coding standard, and in the support-tools and programming-language recommendations, the use of a language subset carries no recommendation at SIL 1 and SIL 2 and is highly recommended at SIL 3 and SIL 4.

MISRA C is the coding standard most Indian embedded teams we work with choose in order to satisfy those requirements, because it is a documented, tool-enforceable language subset with published deviation practice. That is a GSAS observation about what teams pick, not a requirement of IEC 61508, and an assessor will accept any coding standard that does what the standard asks a programming language coding standard to do.

GSAS tools for this obligation

Both tools below are class T2 off-line support tools, since a static analysis tool is one of the standard’s own worked examples of the T2 class. That brings the T2 obligations into play: product documentation defining the tool’s behaviour and the constraints on its use, an assessment of the reliance placed on it and its potential failure mechanisms, and evidence of conformance to specification. A vendor qualification kit is exactly the form of evidence that last item asks for.

• Perforce Helix QAC for coding-standard and MISRA enforcement. Perforce states the product is TUEV SUED certified for compliance with key functional safety standards including IEC 61508 (general industry) up to SIL 4, and claims “100% MISRA coverage”. Both statements are Perforce’s, and should be carried into your safety case as vendor claims backed by the vendor’s certificate. One naming point worth settling before it confuses a tool list: Helix QAC is the current name for what was previously sold as PRQA QA-C and QA-C++, so QA-C and Helix QAC are the same product line and must never appear as two separate tools in a toolchain classification.
• Perforce Klocwork for SAST at CI scale, with incremental, diff-based analysis suited to a Jenkins or GitLab pipeline. Perforce states Klocwork is TUEV SUED certified for IEC 61508 (general industry) up to SIL 4 and ISO 26262 (automotive) up to ASIL D, and supplies TUEV-certified qualification materials.

Note in both cases what the certificate behind those statements actually records. The TUV SUD tool certificates for Helix QAC and Klocwork record a T2 classification and a list of standards tested against; they carry no SIL value. “Up to SIL 4” is Perforce’s characterisation of what that qualification is good for. Both are legitimate things to cite, and GSAS cites both, but they are not interchangeable. The ISO 26262 page records what each Perforce certificate says, certificate number, revision and expiry included.

Obligation 2: dynamic module testing with structural coverage

The standard requires that each software module be verified as required by the software module test specification developed during software system design, that this verification show whether or not each software module performs its intended function and does not perform unintended functions, and that the results of software module testing be documented. Verification here includes testing and analysis, not testing alone.

In the graded recommendations for software module testing and integration, dynamic analysis and testing is recommended at SIL 1 and highly recommended at SIL 2, SIL 3 and SIL 4. Functional and black box testing is highly recommended at all four levels. Test management and automation tools are recommended at SIL 1 and highly recommended from SIL 2 upward. Forward traceability between the software design specification and the module and integration test specifications is recommended at SIL 1 and SIL 2 and highly recommended at SIL 3 and SIL 4.

The structural coverage ladder is the part most commonly misquoted, and the order is not the one most tool marketing implies:

• Entry point coverage at 100 % is highly recommended at every level, SIL 1 included.
• Statement coverage at 100 % is only recommended at SIL 1 and becomes highly recommended at SIL 2.
• Branch coverage at 100 % is recommended at SIL 1 and SIL 2 and becomes highly recommended at SIL 3.
• Condition coverage, MC/DC, at 100 % is recommended at SIL 1, SIL 2 and SIL 3 and becomes highly recommended only at SIL 4.

The same set grades the test-case sources that feed those metrics. Test case execution from boundary value analysis is recommended at SIL 1 and highly recommended from SIL 2. Test case execution from error guessing is recommended at every level. Test case execution from error seeding carries no recommendation at SIL 1 and is recommended from SIL 2. Model-based test case generation is recommended at SIL 1 and SIL 2 and highly recommended at SIL 3 and SIL 4. Performance modelling, and equivalence classes with input partition testing, are recommended up to SIL 3 and highly recommended at SIL 4.

Two qualifications travel with the ladder and belong in your test plan. Where 100 % coverage cannot be achieved, statement coverage of defensive code being the standard’s own example, an appropriate explanation should be given. And the analysis for the test cases is at the subsystem level, based on the specification, or on the specification and the code.

Part 7, the overview of techniques and measures, backs this up on both ends. It sets the aim at 100 % of the selected coverage metric in all cases, and where 100 % cannot be achieved it asks for the reasons to be documented in the test report, giving defensive code that can only be entered if a hardware problem arises as the example. It defines entry point coverage, also called call graph coverage, as ensuring that every subprogram, subroutine or function has been called at least once, and compound condition coverage as exercising every condition in a compound conditional branch linked by AND or OR.

This four-rung ladder is new in Edition 2. IEC’s own commented version records that Edition 1 carried a single “structure based testing” entry, and explains that the term was refined into four specific forms of structural coverage in order to show how each form provides successively greater rigour in line with the intended systematic capability of the software, bringing Part 3 into line with other international standards and guidelines for safety related software.

GSAS tool for this obligation

Razorcat TESSY is a dynamic unit, module and integration testing tool for embedded C and C++ that measures statement, branch, decision, MC/DC and multiple condition coverage, plus entry-point and call-pair coverage, and imports and exports requirements in ReqIF format for bidirectional traceability. Test suites run in batch mode from the command line, so the coverage evidence regenerates inside a Jenkins or GitLab CI pipeline rather than in a pre-audit scramble.

On certification, use Razorcat’s own words. The TESSY 5.1 Safety Manual states that “the core workflow of TESSY as well as the release and test process of the TESSY product has been certified according to ISO 26262-08:2018 and IEC 61508-3:2010”, and that “In the course of the re-certification of TESSY 4.1 by TUEV SUED Rail GmbH the certification was extended to also cover EN 50128 and IEC 62304.” Razorcat further states that “TESSY has been qualified by the German certification authority TUEV SUED Rail GmbH as a testing tool for usage in safety-related software development according to ISO 26262 and IEC 61508”, and that “TESSY was classified as a T2 offline tool in accordance with EN 50128:2011.” No SIL number attaches to TESSY, and you should not let one appear in your safety case.

Two scope limits belong in your tool justification, from the same safety manual. First, the certified core workflow runs “Starting from editing of test data, the core workflow covers test execution, evaluation of test results and report generation”, with “the coverage measurements … verified according to our certified safety plan”; the Classification Tree Editor (CTE), which covers test preparation, “is not part of the certified core workflow of TESSY”. Second, the Tool Qualification Pack (TQP) is an additional purchase and targets DO-178B/C, not IEC 61508.

Obligation 3: trust in the translator and in the pre-existing runtime

The standard requires that, to the extent required by the safety integrity level, the software or design representation selected, including the programming language, have a translator that has been assessed for fitness for purpose, including where appropriate assessment against international or national standards; use only defined language features; match the characteristics of the application; contain features that facilitate the detection of design or programming mistakes; and support features that match the design method.

It names the mechanism for that assessment directly. A validation suite, meaning a set of test programs whose correct translation is known in advance, may be used to evaluate the fitness for purpose of a translator against defined criteria that should include functional and non-functional requirements. For the functional translator requirements, dynamic testing may be the main validation technique, and an automatic testing suite should be used where possible.

The graded recommendations for support tools and programming language put the choices in order:

• A suitable programming language and a strongly typed programming language are highly recommended at every level.
• A language subset carries no recommendation at SIL 1 and SIL 2, and is highly recommended at SIL 3 and SIL 4.
• Certified tools and certified translators are recommended at SIL 1 and highly recommended at SIL 2, SIL 3 and SIL 4.
• Tools and translators with increased confidence from use are highly recommended at every level, SIL 1 included.
• A library of trusted and verified software modules and components is recommended at SIL 1 and highly recommended from SIL 2 upward.

A certificate is not the end of the argument, and the standard qualifies its own recommendation in Part 7: certified tools and certified translators are usually certified only against their respective language or process standards, and are usually not certified in any way with respect to safety. That is precisely why increased confidence from use is highly recommended at every level including SIL 1, while certified tools and certified translators are only recommended at SIL 1. A certificate number and a validation-suite result answer different questions, and the conformance-evidence requirement asks for a suitable combination of successful-use history and tool validation rather than either one alone.

The runtime library is a pre-existing element

The standard requires that a reused pre-existing software element meet one of three compliance routes, Route 1S (compliant development), Route 2S (proven in use) or Route 3S (assessment of a non-compliant development), and also be accompanied by a safety manual that gives a sufficiently precise and complete description of the element to make possible an assessment of the integrity of a specific safety function that depends wholly or partly on that element. It removes any doubt about scope by stating that the requirements on pre-existing elements apply to a run-time library or an interpreter.

The normative requirements for that safety manual set the bar. It has to give a sufficiently precise and complete description, meaning functions, constraints and evidence, to make the integrity assessment possible. It may consist of the element supplier’s documentation where that documentation is adequate. And it has to include all the assumptions made on which the justification for use of the element depends.

That middle allowance is the commercial argument for buying a safety edition rather than qualifying a general-purpose one: a supplier safety manual that is adequate becomes your safety manual.

GSAS tools for this obligation

• Arm Compiler for Embedded FuSa. Arm states on its product support page that the toolchain “has been assessed by safety-accredited certification body” TUV SUD, and that it is “qualified for developing software that meets the highest level of safety integrity for the following standards”: IEC 61508 (Industrial) SIL 3, ISO 26262 (Automotive) ASIL D, EN 50716 (Railways) SIL 4 and IEC 62304 (Medical) Class C. Arm lists the Qualification Kit as a Safety Manual, a Defect Report, a Test Report, a Development Process document and a Release History, with the TUV certificate and a report on that certificate supplied as a separate certification package. Read the railway entry carefully, because Arm names a different railway standard for each product: EN 50716 for the compiler, and EN 50128 for Arm FuSa RTS, which covers the qualified runtime system for Cortex-M. Confirm the applicable revision per tool and per release rather than assuming one answer covers the toolchain. Certification attaches to specific qualified releases, not to every Arm Compiler for Embedded release, so record the exact version in your configuration baseline the way the configuration-management requirements above ask. The Arm Safety Qualification Kit is the documentation package assessors ask for.
• Solid Sands SuperTest. The compiler is a class T3 tool by the standard’s own definition, not by a vendor’s: a T3 off-line support tool generates outputs that can directly or indirectly contribute to the executable code of the safety related system, and an optimising compiler where the relationship between the source code program and the generated object code is not obvious is the standard’s own example of one. Per Solid Sands, SuperTest “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”. That is exactly the validation suite the standard has in mind when it allows a set of test programs whose correct translation is known in advance to be used to evaluate a translator’s fitness for purpose. The SuperTest Qualification Suite is the separate product that packages the result for a tool-confidence argument, and the Solid Sands Compiler Qualification Service states that compiler defects found during qualification “are detailed in a comprehensive qualification report that matches the requirements of the applicable functional safety standard such as ISO 26262, IEC 61508 or EN 50128 / EN 50716”, and that “the report also includes a safety manual that describes the mitigations needed to avoid the compiler defects”.
• Solid Sands SuperGuard for C and C++ standard-library qualification. This is the tool that answers the pre-existing-element requirement head-on, since the standard library is the run-time library that requirement names.
• SEGGER embOS-Safe. SEGGER states that embOS-Safe is certified by TUEV SUED with certification evidence for IEC 61508 SIL 3, IEC 62304 Class C and ISO 26262 ASIL D, supplied with “certificate, safety manual, and supporting documentation”. The certification attaches to the Safe editions, embOS-Classic-Safe and embOS-Ultra-Safe, not to embOS generally. The supplied safety manual is exactly what the standard’s supplier-documentation allowance contemplates.
• Perforce Helix ALM for the traceability recommendations: forward traceability between the software safety requirements specification and the software design, forward traceability into the module and integration test specifications, and forward and backward traceability between the software design specification and the software verification plan. Each of those is recommended at SIL 1 and SIL 2 and highly recommended at SIL 3 and SIL 4.

The GSAS toolchain map for IEC 61508

Obligation	Where it sits in the standard	GSAS-supported tool	Evidence it produces
Static verification of source code against the design and the coding standard	Part 3, code verification by static methods; static analysis in the verification recommendations	Perforce Helix QAC, Perforce Klocwork	Coding-standard and MISRA compliance reports, control flow and data flow findings, deviation records, vendor qualification kit as conformance evidence
Coding standard definition and enforcement	Part 3, programming language coding standard; design and coding standards and language subset recommendations	Perforce Helix QAC	Rule configuration matching a documented language subset, per-rule compliance evidence
Module verification with structural coverage	Part 3, software module testing; the structural coverage ladder	Razorcat TESSY	Entry-point, statement, branch and MC/DC coverage reports plus test results, regenerable in CI
Requirements to test traceability	Part 3, forward and backward traceability recommendations	Perforce Helix ALM, TESSY ReqIF import and export	Forward and backward traceability matrices
Translator fitness for purpose	Part 3, translator assessment and validation suites; certified translators and increased confidence from use	Arm Compiler for Embedded FuSa, Solid Sands SuperTest	TUEV SUED certificate and Qualification Kit; independent compiler validation-suite results
Pre-existing runtime elements	Part 3, pre-existing software elements and the safety manual for compliant items	SEGGER embOS-Safe, Arm FuSa RTS, Solid Sands SuperGuard	Supplier safety manual with assumptions of use; standard-library qualification evidence
Tool version control and requalification	Part 3, configuration management of T2 and T3 tools	Any of the above, recorded in your own configuration management	Tool identity, version, parameters, options and scripts captured per baseline item

The ceiling, stated plainly

Among the tools GSAS supports, the certified compiler (Arm Compiler for Embedded FuSa) and the certified RTOS (SEGGER embOS-Safe) are stated by their vendors at IEC 61508 SIL 3. Only the Perforce static-analysis tools, Helix QAC and Klocwork, carry a vendor-stated IEC 61508 qualification up to SIL 4.

So we do not claim a SIL 4 toolchain, and when anyone does, ask to see the certificate for each component rather than for the bundle. If your target is SIL 4, the compiler and runtime arguments have to be built on the conformance-evidence requirement, on the control-of-failures requirement where that evidence is unavailable, and on the safety manual for pre-existing elements, rather than on a certificate that says SIL 4. Increased confidence from use is highly recommended at every level for exactly this reason. It is also worth remembering that the recommendations are not prescriptive: other measures and techniques may be applied provided the requirements and objectives have been met, and the standard’s own guidance on justifying an alternative is what you take to your assessor.

What GSAS does not claim

• No product “is” qualified for your project. T1, T2 and T3 classification is done by the tool user, for the tool functionalities actually used inside a specific development process. A vendor cannot do it for you, and no tool ships pre-classified.
• A vendor certificate is an input, not the argument. It shortens the conformance-evidence step. It does not replace the classification, the assessment, or the configuration-management work, which stay yours.
• 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 a SIL, an ASIL 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 recommendation tables contain is mandatory. The strongest rating the standard applies is highly recommended, and alternatives may be used where the requirements and objectives are still met, with a rationale agreed with your assessor.
• 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. IEC 61508 is a licensed, copyrighted document. Its clause numbers, subclause numbers, table numbers, row letters and graded recommendation tables are not published here. The one table of numbers on this page, the SIL target failure measure bands, is GSAS engineering guidance in our own words and not a reproduction of the standard. License the parts you need and read them.

Why Indian teams work with GSAS on IEC 61508

GSAS Micro Systems is an engineering partner, operating since 2010, working across 25 partner brands. What matters on an IEC 61508 project is not the catalogue, it is having functional-safety engineers in the same time zone and often the same city as your development team.

Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR do three things on these projects:

1. Classify the toolchain into T1, T2 and T3 using the definitions and worked examples in the definitions part, and write the selection justification and the division of responsibility between you, your compiler vendor and your integrator before an assessor asks for them.
2. Map the target SIL onto the specific recommendations that will be examined. For a SIL 2 industrial controller that means entry-point and statement coverage, control flow and data flow analysis, and the coding-standard constraints that move to highly recommended at SIL 2. For SIL 3 it means adding branch coverage and the language-subset recommendation. The point is to know which recommendations the assessment will actually turn on rather than testing everything to SIL 4 rigour.
3. Wire the evidence into your existing pipeline, so that Helix QAC or Klocwork reports and TESSY coverage results regenerate on every commit in Jenkins or GitLab CI, and the tool version, parameters and scripts land in the configuration baseline the way the standard’s configuration-management requirements ask.

GSAS has physical offices in Bengaluru (corporate headquarters and primary engineering hub), Chennai, Coimbatore, Delhi NCR, Hyderabad, Mumbai, Pune, Vadodara and Visakhapatnam, so a toolchain classification workshop or a coverage-gap review for an IEC 61508 programme in Pune, Bengaluru or Hyderabad happens on site with an engineer who has done it before. Training on the individual tools is available through GSAS training, and the broader engineering offer is described on functional safety.

Frequently asked questions about IEC 61508

What is the difference between IEC 61508 and ISO 26262?

IEC 61508 is the generic standard for functional safety of E/E/PE safety-related systems across sectors. ISO 26262 declares itself the adaptation of the IEC 61508 series to the sector specific needs of electrical and electronic systems within road vehicles. For a software team the most visible practical difference is the tool argument. IEC 61508 uses the T1, T2 and T3 off-line tool classification from its definitions part, with the obligations scoped by class and identical at every SIL. The automotive scheme is structured differently, around tool impact, tool error detection and a tool confidence level assigned by the tool user; see our ISO 26262 page for how tool qualification works there.

Which SIL does my application need?

IEC 61508 does not answer that and neither should a tool vendor. SIL is the output of a risk analysis, and IEC 61508-5 is titled “Examples of methods for the determination of safety integrity levels”. Whatever the answer, IEC 61508 requires it to be expressed as an average probability of a dangerous failure on demand for low demand mode, or an average frequency of a dangerous failure per hour for high demand or continuous mode. Once you have a target SIL, GSAS can scope the toolchain and the graded recommendations that follow from it.

Does IEC 61508 require MISRA C?

No. IEC 61508 does not name MISRA, or any other particular coding standard, as the one to use. It requires a suitable programming language coding standard, says what that standard has to do, and rates the use of a language subset as highly recommended at SIL 3 and SIL 4. MISRA C is a common way to satisfy those requirements and it is the choice most Indian teams we work with make, but any coding standard that meets the standard’s requirements for a coding standard is acceptable to an assessor.

What does tool qualification actually involve under IEC 61508?

Classify each off-line tool as T1, T2 or T3 using the standard’s definitions, and justify the selection. For T2 and T3, hold a specification or product documentation defining the tool’s behaviour and the constraints on its use, and assess the reliance placed on the tool and its potential failure mechanisms, taking mitigations where mechanisms are identified. For T3, hold evidence that the tool conforms to its specification, from a suitable combination of successful-use history and tool validation; where that evidence is unavailable, put effective measures in place to control the resulting failures. If you validate, document the full record the standard asks for, from the chronological log of activities through to the discrepancies between expected and actual results. Then keep the tool version, parameters, options and scripts in the configuration baseline, and requalify each new version. A vendor certificate and qualification kit shortens the conformance-evidence step; it does not replace the classification, the assessment or the configuration-management work, which stay yours.

Can IEC 61508-qualified tools be used for the sector standards?

Often, but check what the vendor’s certificate actually covers rather than assuming derivation. IEC 61508 names only IEC 61511, IEC 62061 and IEC 61800-5-2 as examples of sector standards based on the series. ISO 26262 declares itself an adaptation of IEC 61508. Razorcat states that EN 50128:2011 is an application standard derived from IEC 61508, and EN 50716 has since superseded EN 50128 in the BSI catalogue. Several of the tools above carry multi-standard certificates in their own right: Perforce states Helix QAC and Klocwork are certified for ISO 26262 up to ASIL D as well as IEC 61508 up to SIL 4, Arm states IEC 61508 SIL 3, ISO 26262 ASIL D, EN 50716 (Railways) SIL 4 and IEC 62304 Class C for Arm Compiler for Embedded FuSa while naming EN 50128 rather than EN 50716 for Arm FuSa RTS, and SEGGER states IEC 61508 SIL 3, IEC 62304 Class C and ISO 26262 ASIL D for embOS-Safe. The Arm split is the reason to check the standard and the revision per tool rather than per vendor.

What is the highest SIL the GSAS toolchain is qualified for?

The Perforce static-analysis tools carry a vendor-stated IEC 61508 qualification up to SIL 4. The compiler and RTOS we supply are stated by Arm and SEGGER at IEC 61508 SIL 3. We do not market a SIL 4 toolchain, because the vendors of two of its most important components state SIL 3.

What drives the cost of an IEC 61508 software programme?

Scope drives it. The target SIL sets which graded recommendations move from recommended to highly recommended, and each one that is not already covered by your process becomes work: additional structural coverage levels, additional static-analysis techniques, additional coding-standard constraints. Beyond that, the number of tools you have to classify and justify, the maturity of your existing configuration management, and whether your compiler and runtime already ship qualification evidence all move the number. Contact GSAS with your target SIL and toolchain and we will scope the tooling side of it.

Which programming languages does the GSAS IEC 61508 toolchain cover?

C and C++, which dominate industrial embedded development. TESSY performs unit, module and integration testing for embedded C and C++. Solid Sands SuperTest validates C and C++ compilers against the ISO language standards, and SuperGuard qualifies C and C++ standard libraries. Perforce Helix QAC analyses C and C++; Perforce states that Klocwork additionally covers C#, Rust, Java, JavaScript, Python and Kotlin.

Get started

Whether you are classifying a toolchain for a first IEC 61508 assessment, raising an existing controller from SIL 2 to SIL 3, or preparing evidence for a TUEV assessment, GSAS can map your target SIL onto the specific obligations and recommendations that will be examined, and supply the tools that generate the evidence.

Talk to a compliance specialist

Bring your target SIL, your current toolchain and your CI setup. We will come back with a tool classification, a SIL-scoped recommendation map and a quotation.

---

Sources for this page: IEC’s public catalogue entry and abstract for IEC 61508-3:2010; the BSI catalogue entry for BS EN 50716:2023; the Razorcat TESSY 5.1 Safety Manual; TUV SUD Product Service certificate Z10 078930 0004 Rev. 01 (TESSY), with the Helix QAC and Klocwork certificate scopes recorded on the ISO 26262 page; Arm’s product support pages for Arm Compiler for Embedded FuSa and FuSa RTS, which name different railway standards; and the Perforce, Razorcat, Solid Sands and SEGGER product and datasheet pages cited inline. Statements about what IEC 61508 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: ISO 26262 automotive safety | DO-178C aerospace | MISRA and AUTOSAR compliance

Related solutions: Industrial automation | Railway | Functional safety capability