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 where is the evidence required for each class. IEC 61508-3:2010 answers that question in clause 7.4.4 and in IEC 61508-4:2010 definitions 3.2.10 and 3.2.11, and it answers it in a way that has nothing to do with buying a certificate.

This page is a clause-to-tool map. It states what the standard actually says, with the clause, table and annex reference for every normative claim, 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.

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).

The Foreword of Part 3 records that “This second edition cancels and replaces the first edition published in 1998” and that “This edition constitutes a technical revision”. Part 3 was prepared by IEC subcommittee 65A (System aspects) of IEC technical committee 65 (Industrial-process measurement, control and automation), and “It has the status of a basic safety publication according to IEC Guide 104”.

The series has seven parts:

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

The Introduction to Part 3 states that “A major objective is to facilitate the development of product and application sector international standards based on the IEC 61508 series”, and NOTE 1 to that Introduction points to bibliography references [1], [2] and [3] for examples. Those three references are 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 self-declares the relationship in the first sentence of the Introduction to ISO 26262-1:2018: “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.” 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.

Safety integrity levels are two tables, not one number

IEC 61508-1:2010, clause 7.6.2.9 requires the safety integrity requirement for each safety function to be specified in accordance with Table 2 or Table 3 and to be qualified as either an average probability of a dangerous failure on demand (PFDavg, low demand mode, Table 2) or an average frequency of a dangerous failure per hour (PFH, high demand or continuous mode, Table 3). A SIL claim that does not say which mode it refers to is incomplete.

SIL	Table 2, low demand mode: PFDavg	Table 3, high demand or continuous mode: PFH (h-1)
SIL 4	>= 10^-5 to < 10^-4	>= 10^-9 to < 10^-8
SIL 3	>= 10^-4 to < 10^-3	>= 10^-8 to < 10^-7
SIL 2	>= 10^-3 to < 10^-2	>= 10^-7 to < 10^-6
SIL 1	>= 10^-2 to < 10^-1	>= 10^-6 to < 10^-5

Two things around those tables matter more than the numbers themselves. The first is normative. Clause 7.6.2.12 states that “No single safety function in an E/E/PE safety-related system shall be allocated a target safety integrity failure measure lower than specified in Tables 2 and 3”, setting the lower limit 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. Its NOTE adds that lower values may be achievable for non-complex systems, “but these limits are considered to represent what can be achieved for relatively complex systems (for example 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 a pair of notes under the tables about what can actually be calculated. NOTE 3 records that “it will not be possible to predict quantitatively the safety integrity of all aspects of E/E/PE safety-related systems. Qualitative techniques, measures and judgements will have to be made”, and that this “is particularly true in the case of systematic safety integrity”. NOTE 4 confines the arithmetic to the other half: “For hardware safety integrity it is necessary to apply quantified reliability estimation techniques in order to assess whether the target safety integrity, as determined by the risk assessment, has been achieved, taking into account random hardware failures”. Software work is systematic safety integrity, so everything below in 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 that gives examples of methods for determining it.

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

Figure 6 of IEC 61508-3:2010 is titled “Software systematic capability and the development lifecycle (the V-model)”. 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. Clause 7.1.2.2 states that “Any software lifecycle model may be used provided all the objectives and requirements of this clause are met”. Clause 7.1.2.4 states that “it is acceptable to tailor the depth, number and work-size of the phases of V-model (see Figure 6) to take account of the safety integrity and the complexity of the project”. Clause 7.1.2.5 attaches the condition: “Any customisation of the software safety lifecycle shall be justified on the basis of functional safety.” That clause 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 Annex A and Annex B

Annex A of IEC 61508-3:2010 is normative and is titled “Guide to the selection of techniques and measures”. Annex B is informative and is titled “Detailed tables”; it was normative in Edition 1 and became informative in Edition 2. Annex C is informative. Annex D is normative, “Safety manual for compliant items: additional requirements for software elements”. Annexes E, F and G are informative.

The Annex A introduction defines the recommendation codes:

Code	Meaning per the Annex A introduction
HR	Highly recommended for this safety integrity level. If not used, “the rationale behind not using it should be detailed with reference to Annex C during the safety planning and agreed with the assessor”
R	Recommended “as a lower recommendation to a HR recommendation”
---	“no recommendation for or against being used”
NR	”positively not recommended for this safety integrity level”. If used, the rationale must be detailed with reference to Annex C and agreed with the assessor

The same introduction states that “More detailed tables in Annex B expand upon some of the entries in the tables of Annex A. For example, Table B.2 expands on the topic of dynamic analysis and testing in Table A.5.” It also states, and this is the sentence most vendor pages omit, that “Other measures and techniques may be applied providing that the requirements and objectives have been met.”

The Annex A tables are: A.1 Software safety requirements specification; A.2 Software design and development, software architecture design; A.3 Software design and development, support tools and programming language; A.4 Software design and development, detailed design; A.5 Software design and development, software module testing and integration; A.6 Programmable electronics integration (hardware and software); A.7 Software aspects of system safety validation; A.8 Modification; A.9 Software verification; A.10 Functional safety assessment.

The Annex B tables are: B.1 Design and coding standards; B.2 Dynamic analysis and testing; B.3 Functional and black-box testing; B.4 Failure analysis; B.5 Modelling; B.6 Performance testing; B.7 Semi-formal methods; B.8 Static analysis; B.9 Modular approach.

Tool classification is your first deliverable

Clause 7.4.4 of IEC 61508-3:2010 is titled “Requirements for support tools, including programming languages”. It sits between 7.4.3 (software architecture design) and 7.4.5 (detailed design and development), ahead of 7.4.6 code implementation, 7.4.7 software module testing and 7.4.8 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. Definition 3.2.10 defines a “software on-line support tool” as a “software tool that can directly influence the safety-related system during its run time”. Definition 3.2.11 defines a “software off-line support tool” as a “software tool that supports a phase of the software development lifecycle and that cannot directly influence the safety-related system during its run time”, and divides off-line tools into three classes.

Class	Definition, verbatim from IEC 61508-4:2010, 3.2.11	The standard’s own examples
T1	”generates no outputs which can directly or indirectly contribute to the executable code (including data) of the safety related system”	NOTE 1: “a text editor or a requirements or design support tool with no automatic code generation capabilities; configuration control tools”
T2	”supports the test or verification of the design or executable code, where errors in the tool can fail to reveal defects but cannot directly create errors in the executable software”	NOTE 2: “a test harness generator; a test coverage measurement tool; a static analysis tool”
T3	”generates outputs which can directly or indirectly contribute to the executable code of the safety related system”	NOTE 3: “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. Clause 7.4.4.1 states that “A software on-line support tool shall be considered to be a software element of the safety-related system.”

What the standard then requires of each class

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

• 7.4.4.4 All off-line support tools in classes T2 and T3 “shall have a specification or product documentation which clearly defines the behaviour of the tool and any instructions or constraints on its use”. Its NOTE is explicit that this specification or product documentation is not the same thing as an Annex D safety manual for a compliant item.
• 7.4.4.5 An assessment “shall be carried out for offline support tools in classes T2 and T3 to determine the level of reliance placed on the tools, and the potential failure mechanisms of the tools that may affect the executable software. Where such failure mechanisms are identified, appropriate mitigation measures shall be taken.” NOTE 2 lists the mitigations: “avoiding known bugs, restricted use of the tool functionality, checking the tool output, use of diverse tools for the same purpose.”
• 7.4.4.6 “For each tool in class T3, evidence shall be available that the tool conforms to its specification or documentation. Evidence may be based on a suitable combination of history of successful use in similar environments and for similar applications (within the organisation or other organisations), and of tool validation as specified in 7.4.4.7.” NOTE 2 adds that “The evidence listed for T3 may also be used for T2 tools in judging the correctness of their results.”
• 7.4.4.7 Where validation is used, the documented results must cover seven items: a) a chronological record of the validation activities; b) the version of the tool product manual being used; c) the tool functions being validated; d) tools and equipment used; e) the results of the validation activity, stating either that the software passed or the reasons for failure; f) test cases and their results for subsequent analysis; g) discrepancies between expected and actual results.
• 7.4.4.8 “Where the conformance evidence of 7.4.4.6 is unavailable, there shall be effective measures to control failures of the executable safety related system that result from faults that are attributable to the tool.”

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

Tools live in the configuration baseline

Clauses 7.4.4.15 to 7.4.4.18 are the part most teams discover late. Where T2 and T3 tools generate items in the configuration baseline, configuration management shall record the identification of the tool and its version, the baseline items the 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 “shall ensure that for tools in classes T2 and T3, only qualified versions are used”, and “Each new version of off-line support tool shall be qualified”, though 7.4.4.18 allows that qualification to rely on evidence from an earlier version under stated conditions.

Finally, 7.4.4.19 states that responsibility for conformance with 7.4.4 “can rest with multiple parties”, and that “The division of responsibility shall 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.

Clause 7.4.4.2 NOTE 2 gives the categories of off-line tool the standard 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 … compilers, assemblers, linkers, binders, loaders and code generation tools”. Those two bullets map almost exactly onto the three obligations below.

Obligation 1: static verification of the source code

Clause 7.9.2.12 is the requirement, and it is unconditional: “Verification of code: the source code shall be verified by static methods to ensure conformance to the software module design specification (see 7.4.5), the required coding standards (see 7.4.4), and the validation plan for software aspects of safety (see 7.3).” Its NOTE 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.

Table A.9 “Software verification (See 7.9)” rates row 3, static analysis, pointing to Table B.8, as R at SIL 1 and HR at SIL 2, SIL 3 and SIL 4. NOTE 1 to that table explains that “For convenience all verification activities have been drawn together under this table.”

Table B.8 “Static analysis (Referenced by Table A.9)” is where the rating becomes concrete:

Table B.8 row	Technique/Measure	SIL 1	SIL 2	SIL 3	SIL 4
1	Boundary value analysis	R	R	HR	HR
2	Checklists	R	R	R	R
3	Control flow analysis	R	HR	HR	HR
4	Data flow analysis	R	HR	HR	HR
5	Error guessing	R	R	R	R
9	Static analysis of run time error behaviour	R	R	R	HR
10	Worst-case execution time analysis	R	R	R	R

Control flow and data flow analysis are both HR from SIL 2 upward. Static analysis of run-time error behaviour becomes HR only at SIL 4, which is worth knowing before you commit a SIL 2 project to an abstract-interpretation budget.

The coding standard the code is verified against

Clause 7.4.4.12 states that “Programming languages for the development of all safety-related software shall be used according to a suitable programming language coding standard.” Clause 7.4.4.13 defines what that standard must do: “specify good programming practice, proscribe unsafe language features (for example, undefined language features, unstructured designs, etc.), promote code understandability, facilitate verification and testing, and specify procedures for source code documentation.”

Table A.4 (detailed design) rates row 5, design and coding standards, pointing to Table B.1, as R at SIL 1 and HR at SIL 2, SIL 3 and SIL 4. Row 3, defensive programming, is --- at SIL 1, R at SIL 2 and HR at SIL 3 and SIL 4. Row 4, the modular approach pointing to Table B.9, is HR at all four levels.

Table B.1 “Design and coding standards (Referenced by Table A.4)” is the graded rule set itself:

Technique/Measure	SIL 1	SIL 2	SIL 3	SIL 4
Use of coding standard to reduce likelihood of errors	HR	HR	HR	HR
No dynamic objects	R	HR	HR	HR
No dynamic variables	---	R	HR	HR
Limited use of interrupts	R	R	HR	HR
Limited use of pointers	---	R	HR	HR
Limited use of recursion	---	R	HR	HR
No unconditional jumps in programs in higher level languages	R	HR	HR	HR
No automatic type conversion	R	HR	HR	HR

NOTE 1 to Table B.1 carries a carve-out that is worth reading before a team bans dynamic allocation outright. The measures “No dynamic objects”, “No dynamic variables” and “Limited use of pointers” “do not need to be applied if a compiler is used which ensures a) that sufficient memory for all dynamic variables and objects will be allocated before runtime, or which guarantees that in case of memory allocation error, a safe state is achieved; b) that response times meet the requirements.”

Where MISRA C actually fits

IEC 61508 never names MISRA. A full-text search of the 670-page IEC commented version of IEC 61508:2010, covering Parts 1 to 7, returns zero occurrences of the string. What the standard requires is “a suitable programming language coding standard” (7.4.4.12 and 7.4.4.13), and Table A.3 row 3 rates “Language subset” as --- at SIL 1 and SIL 2 and HR 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 meets 7.4.4.13.

GSAS tools for this obligation

Both tools below are class T2 off-line support tools under IEC 61508-4 3.2.11, whose NOTE 2 names “a static analysis tool” as its own T2 example. That means 7.4.4.4 to 7.4.4.6 apply, and a vendor qualification kit is exactly the form of evidence 7.4.4.6 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.

Obligation 2: dynamic module testing with structural coverage

Clause 7.4.7.1 states that “Each software module shall be verified as required by the software module test specification that was developed during software system design (see 7.4.5)”, and its NOTE adds that “Verification includes testing and analysis.” Clause 7.4.7.2 states that “This verification shall show whether or not each software module performs its intended function and does not perform unintended functions.” Clause 7.4.7.3 states that “The results of the software module testing shall be documented.”

Table A.5 “Software design and development, software module testing and integration (See 7.4.7 and 7.4.8)” rates row 2, dynamic analysis and testing, pointing to Table B.2, as R at SIL 1 and HR at SIL 2, SIL 3 and SIL 4. Row 4, functional and black box testing, is HR at all four levels. Row 8, test management and automation tools, is R at SIL 1 and HR at SIL 2, 3 and 4. Row 9, forward traceability between the software design specification and the module and integration test specifications, is R at SIL 1 and SIL 2 and HR at SIL 3 and SIL 4.

Table B.2 is the real coverage ladder, and it is the table most commonly misquoted:

Table B.2 row	Technique/Measure	SIL 1	SIL 2	SIL 3	SIL 4
1	Test case execution from boundary value analysis	R	HR	HR	HR
2	Test case execution from error guessing	R	R	R	R
3	Test case execution from error seeding	---	R	R	R
4	Test case execution from model-based test case generation	R	R	HR	HR
5	Performance modelling	R	R	R	HR
6	Equivalence classes and input partition testing	R	R	R	HR
7a	Structural test coverage (entry points) 100 %	HR	HR	HR	HR
7b	Structural test coverage (statements) 100 %	R	HR	HR	HR
7c	Structural test coverage (branches) 100 %	R	R	HR	HR
7d	Structural test coverage (conditions, MC/DC) 100 %	R	R	R	HR

Read the ladder carefully, because the order is not the one most tool marketing implies. Entry-point coverage is HR at every level including SIL 1. Statement coverage is only R at SIL 1 and becomes HR at SIL 2. Branch coverage is R until SIL 3. MC/DC is R at SIL 1, 2 and 3 and becomes HR only at SIL 4. Table B.2 carries the footnote that “Where 100 % coverage cannot be achieved (e.g. statement coverage of defensive code), an appropriate explanation should be given”, and NOTE 1 that “The analysis for the test cases is at the subsystem level and is based on the specification and/or the specification and the code.”

IEC 61508-7:2010, C.5.8 “Structure-based testing” backs this up on both ends. It states that “In all cases, 100 % of the selected coverage metric should be the aim; if it is not possible to achieve 100 % coverage, the reasons why 100 % cannot be achieved should be documented in the test report (for example, defensive code which can only be entered if a hardware problem arises).” It defines entry point (call graph) coverage as ensuring “that every subprogram (subroutine or function) has been called at least once”, and compound conditions as “every condition in a compound conditional branch (i.e. linked by AND/OR) is exercised”.

This four-rung ladder is new in Edition 2. IEC’s own commented version notes that in Edition 1 this was a single row, “structure based testing”, and explains that “The term ‘structure based testing’ has been refined to list four specific forms of structural coverage which can be achieved, and to show how each form of structural coverage provides successively greater rigour in line with the intended systematic capability of the software. This brings IEC 61508-3 ed2.0 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 modified condition combination 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 Table B.2 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

Clause 7.4.4.10 states that, to the extent required by the safety integrity level, the software or design representation selected, including a programming language, shall: a) “have a translator which has been assessed for fitness for purpose including, where appropriate, assessment against the international or national standards”; b) “use only defined language features”; c) “match the characteristics of the application”; d) “contain features that facilitate the detection of design or programming mistakes”; e) “support features that match the design method”.

NOTE 3 to 7.4.4.10 names the mechanism directly: “A validation suite (i.e. a set of test programs whose correct translation is known in advance) may be used to evaluate the fitness for purpose of a translator according to defined criteria, which should include functional and non-functional requirements. For the functional translator requirements, dynamic testing may be a main validation technique. If possible an automatic testing suite should be used.”

Table A.3 “Software design and development, support tools and programming language (See 7.4.4)” grades the choices:

Table A.3 row	Technique/Measure	SIL 1	SIL 2	SIL 3	SIL 4
1	Suitable programming language	HR	HR	HR	HR
2	Strongly typed programming language	HR	HR	HR	HR
3	Language subset	---	---	HR	HR
4a	Certified tools and certified translators	R	HR	HR	HR
4b	Tools and translators: increased confidence from use	HR	HR	HR	HR
	Library of trusted/verified software modules and components	R	HR	HR	HR

A certificate is not the end of the argument. IEC 61508-7:2010, C.4.3 qualifies its own recommendation: “certified tools and certified translators are usually certified only against their respective language or process standards. They are usually not certified in any way with respect to safety.” That is precisely why row 4b, increased confidence from use, is HR at every level including SIL 1 while row 4a, certified tools and certified translators, is only R at SIL 1. A certificate number and a validation-suite result answer different questions, and 7.4.4.6 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

Clause 7.4.2.12 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 non-compliant development per 7.4.2.13), and also be accompanied by “a safety manual (see Annex D of IEC 61508-2 and Annex D of this standard) 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 the pre-existing software element”. NOTE 3 to that clause removes any doubt about scope: “Requirements on pre-existing elements apply to a run-time library or an interpreter.”

Annex D, which is normative, sets the bar for that safety manual. D.1.1 requires “a sufficiently precise and complete description (i.e. functions, constraints and evidence), to make possible an assessment of the integrity of a specific safety function that depends wholly or partly on the element”, implemented by means of a safety manual. D.1.2 allows that “The safety manual may consist of the element supplier’s documentation if this is adequate.” D.2.3 c) requires that “The safety manual shall include all the assumptions made on which the justification for use of the element depends.”

That single sentence in D.1.2 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 that the compiler “is assessed and provided with a certificate and report to the certificate by safety experts TUEV SUED”, qualified to IEC 61508 SIL 3, ISO 26262 ASIL D, EN 50128 SIL 4 and IEC 62304 Class C, and supplied with “a comprehensive Qualification Kit including the Development Process report, Release History, Safety Manual, and Testing report”. Certification attaches to specific qualified releases, not to every Arm Compiler for Embedded release, so record the exact version in your configuration baseline as 7.4.4.15 requires. The Arm Safety Qualification Kit is the documentation package assessors ask for, and Arm FuSa RTS covers the qualified runtime system for Cortex-M.
• Solid Sands SuperTest. The compiler is a class T3 tool by the standard’s own definition, not by a vendor’s: IEC 61508-4:2010, 3.2.11 defines T3 as an off-line support tool that “generates outputs which can directly or indirectly contribute to the executable code of the safety related system”, and its NOTE 3 gives “an optimising compiler where the relationship between the source code program and the generated object code is not obvious” as the example. 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 what 7.4.4.10 NOTE 3 has in mind when it allows “a validation suite (i.e. 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 7.4.2.12 NOTE 3 head-on, since the standard library is the run-time library the note is talking about.
• 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 what D.1.2 contemplates.
• Perforce Helix ALM for the traceability rows: Table A.4 row 8 (forward traceability between the software safety requirements specification and software design, R at SIL 1 and 2, HR at SIL 3 and 4), Table A.5 row 9 (forward traceability into the module and integration test specifications, R at SIL 1 and 2, HR at SIL 3 and 4), and Table A.9 rows 5 and 6 (forward and backward traceability between the software design specification and the software verification plan, R at SIL 1 and 2, HR at SIL 3 and 4).

The GSAS toolchain map for IEC 61508

Obligation	Clause and table reference	GSAS-supported tool	Evidence it produces
Static verification of source code against the design and the coding standard	7.9.2.12; Table A.9 row 3; Table B.8 rows 3, 4, 9	Perforce Helix QAC, Perforce Klocwork	Coding-standard and MISRA compliance reports, control flow and data flow findings, deviation records, vendor qualification kit for 7.4.4.6
Coding standard definition and enforcement	7.4.4.12, 7.4.4.13; Table A.4 row 5; Table B.1; Table A.3 row 3	Perforce Helix QAC	Rule configuration matching a documented language subset, per-rule compliance evidence
Module verification with structural coverage	7.4.7.1 to 7.4.7.3; Table A.5 row 2; Table B.2 rows 7a to 7d	Razorcat TESSY	Entry-point, statement, branch and MC/DC coverage reports plus test results, regenerable in CI
Requirements to test traceability	Table A.4 row 8; Table A.5 row 9; Table A.9 rows 5 and 6	Perforce Helix ALM, TESSY ReqIF import and export	Forward and backward traceability matrices
Translator fitness for purpose	7.4.4.10 a) and NOTE 3; Table A.3 rows 4a and 4b	Arm Compiler for Embedded FuSa, Solid Sands SuperTest	TUEV SUED certificate and Qualification Kit; independent compiler validation-suite results
Pre-existing runtime elements	7.4.2.12 and NOTE 3; Annex D, D.1.1, D.1.2, D.2.3 c)	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	7.4.4.15 to 7.4.4.18	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 7.4.4.6, 7.4.4.8 and Annex D rather than on a certificate that says SIL 4, and Table A.3 row 4b, “tools and translators: increased confidence from use”, is HR at every level for exactly this reason. It is also worth remembering that the Annex A recommendations are not prescriptive: the Annex A introduction states that “Other measures and techniques may be applied providing that the requirements and objectives have been met”, with Annex C as the guidance for justifying the alternative to your assessor.

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 IEC 61508-4 3.2.11 definitions and examples, and write the 7.4.4.3 justification and the 7.4.4.19 division of responsibility before an assessor asks for them.
2. Map the target SIL onto specific table rows. For a SIL 2 industrial controller that means Table B.2 rows 7a and 7b, Table B.8 rows 3 and 4, and the Table B.1 rows that flip to HR at SIL 2. For SIL 3 it means adding branch coverage and the language-subset row. The point is to know which rows 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 7.4.4.15 requires.

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 its own relationship in the first sentence of the Introduction to ISO 26262-1:2018: “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.” For a software team the most visible practical difference is the tool argument. IEC 61508 uses the T1, T2, T3 classification of IEC 61508-4 3.2.11, with the obligations in 7.4.4.4 to 7.4.4.8 scoped by class and identical at every SIL. The automotive scheme is structured differently; 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, clause 7.6.2.9 of IEC 61508-1 requires it to be expressed as a PFDavg against Table 2 for low demand mode or a PFH against Table 3 for high demand or continuous mode. Once you have a target SIL, GSAS can scope the toolchain and the Annex A and Annex B rows that follow from it.

Does IEC 61508 require MISRA C?

No. The string “MISRA” does not appear anywhere in IEC 61508 Parts 1 to 7. Clause 7.4.4.12 requires “a suitable programming language coding standard”, clause 7.4.4.13 says what that standard must do, and Table A.3 row 3 rates “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 meeting 7.4.4.13 is acceptable to an assessor.

What does tool qualification actually involve under IEC 61508?

Classify each off-line tool as T1, T2 or T3 per IEC 61508-4 3.2.11 and justify the selection under 7.4.4.3. For T2 and T3, hold a specification or product documentation defining the tool’s behaviour and constraints on its use (7.4.4.4), assess the reliance placed on the tool and its potential failure mechanisms and take mitigations (7.4.4.5). For T3, hold evidence that the tool conforms to its specification, from a suitable combination of successful-use history and tool validation (7.4.4.6), and where that evidence is unavailable, put effective measures in place to control the resulting failures (7.4.4.8). If you validate, document the seven items in 7.4.4.7. Then keep the tool version, parameters, options and scripts in the configuration baseline (7.4.4.15) and requalify each new version (7.4.4.18). A vendor certificate and qualification kit shortens the 7.4.4.6 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 50128 SIL 4 and IEC 62304 Class C for Arm Compiler for Embedded FuSa, and SEGGER states IEC 61508 SIL 3, IEC 62304 Class C and ISO 26262 ASIL D for embOS-Safe.

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 certificates behind two of its most important components say SIL 3.

What drives the cost of an IEC 61508 software programme?

Scope drives it. The target SIL sets which Annex A and Annex B rows move from R to HR, and each HR row that is not already covered by your process becomes work: additional coverage levels in Table B.2, additional static-analysis techniques in Table B.8, additional coding-standard constraints in Table B.1. Beyond that, the number of tools you have to classify and justify under 7.4.4, 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 clauses and table rows 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 table-row map and a quotation.

Related compliance pages: ISO 26262 automotive safety | DO-178C aerospace | MISRA and AUTOSAR compliance

Related solutions: Industrial automation | Railway | Functional safety capability