IEC 61511 ↔ IEC 61508
Where process-sector SIS work sits under IEC 61511-1, and the points at which it routes back to IEC 61508.
Editions this page is written against
| Document | Edition assumed here |
|---|---|
| Process-sector application standard | IEC 61511-1:2016+AMD1:2017 (Part 1, normative). Parts 2 and 3 are guidance documents, not requirements. |
| Foundation standard | IEC 61508:2010 (Parts 1–7 as applicable). Parts 1–3 carry the requirements normally reached from IEC 61511 work; Parts 4–7 are definitions and guidance. |
Clause numbering below is the IEC 61511-1:2016 structure. Earlier editions numbered the lifecycle differently, so a clause reference copied from an older document will not line up — check which edition a citation came from before relying on it. If your project is governed by a national adoption (for example the US ISA/IEC 61511 series), verify clause numbering and any national deviations against that adoption rather than against this page.
What this page is. A routing aid: which standard governs which activity, and what evidence each route needs. It is not a compliance checklist, and no statement here substitutes for reading the governing edition.
Purpose
IEC 61508 is the foundation standard for functional safety of electrical, electronic, and programmable electronic (E/E/PE) safety-related systems. Its scope is not tied to an industry — it covers the whole safety lifecycle for any E/E/PE safety-related system, including the development of the devices such systems are built from.
IEC 61511 is the process-sector application of that framework, scoped to Safety Instrumented Systems (SIS) in process plants. It restructures the IEC 61508 lifecycle into clauses that follow how a process SIS is actually specified, built, operated, and retired, and it recognises evidence routes for field hardware that suit equipment with a long service history.
In practice: an owner-operator, integrator, or design engineer working on a process SIS normally works to IEC 61511-1 throughout. IEC 61508 is reached when a device or subsystem has to be developed and assessed rather than selected — which is usually the device manufacturer’s work, not the plant engineer’s — or where the governing project specification requires it directly.
flowchart TD
A[Process SIS scope] --> B[IEC 61511-1 lifecycle
Clauses 8 to 18]
B --> C[Clause 11
SIS design and engineering]
C --> D{How is this hardware
justified?}
D -->|Documented service history
in comparable conditions| E[Prior-use route
evidence held by the user]
D -->|Developed and assessed
against IEC 61508| F[IEC 61508 route
evidence held by the developer]
E --> G[SIF-level verification
against the SRS]
F --> G
G --> H[Clause 15 validation, then
Clauses 16 to 18 in service]
Original diagram — a routing sketch of the two evidence paths, not a reproduction of any figure in either standard.
Relationship at a glance
| Aspect | IEC 61508:2010 | IEC 61511-1:2016+AMD1:2017 |
|---|---|---|
| Scope | E/E/PE safety-related systems generally, across sectors | Safety instrumented systems in the process sector |
| Typical user | Developers of safety devices, logic solvers, and safety-related subsystems | Owner-operators, SIS integrators, process design and safety engineers |
| Demand mode emphasis | Low-demand and high-demand/continuous both addressed | Written around low-demand process protection, where PFDavg is the usual working metric; the 2016 edition also addresses high-demand and continuous mode, where PFH applies |
| Hardware evidence | Development and assessment against Parts 2 and 3 | Two routes — prior use, or IEC 61508 assessment (see below) |
| Software | Full Part 3 treatment for embedded/system software | Application programming (Clause 12) on a logic solver whose embedded software was assessed elsewhere |
| Relationship | Foundation | Sector application that invokes the foundation where needed |
The corpus notes record that IEC 61511 addresses SIL 1–3 and directs SIL 4 safety instrumented functions back to IEC 61508; confirm that boundary against the governing edition before relying on it for a specific project.
SIL bands are not restated here. Numeric PFDavg ranges belong with the standards they come from — see the IEC 61511 and IEC 61508 pages, and confirm against the governing edition.
Lifecycle routing — IEC 61511-1 Clauses 8–18
The IEC 61508-1 overall safety lifecycle (Clause 7) is a sixteen-phase structure. The IEC 61511-1 clauses are the process-sector expression of it. The mapping below is a routing aid — the correspondence is one of intent, not a clause-for-clause equivalence, and several IEC 61511 clauses touch more than one IEC 61508 phase.
| IEC 61511-1 clause | Subject | Corresponding IEC 61508-1 lifecycle phases |
|---|---|---|
| Clause 8 | Process hazard and risk assessment | Phases 1–3 — concept, overall scope definition, hazard and risk analysis |
| Clause 9 | Allocation of safety functions to protection layers | Phases 4–5 — overall safety requirements, and their allocation to protection layers |
| Clause 10 | SIS safety requirements specification (SRS) | The E/E/PE safety requirements that Phase 9 realisation works from |
| Clause 11 | SIS design and engineering | Phase 9 — E/E/PE system realisation, applying IEC 61508-2 for hardware |
| Clause 12 | SIS application programming | Phase 9 realisation, on the software side (IEC 61508-3) |
| Clause 13 | Factory acceptance testing (FAT) | Verification within Phase 9 realisation |
| Clause 14 | SIS installation and commissioning | Phase 12 — overall installation and commissioning (the planning for it sits earlier, at Phase 8) |
| Clause 15 | SIS safety validation | Phases 7 and 13 — validation planning and overall safety validation |
| Clause 16 | SIS operation and maintenance, including proof testing and inspection | Phases 6 and 14 — operation and maintenance planning, and operation, maintenance and repair |
| Clause 17 | SIS modification | Phase 15 — overall modification |
| Clause 18 | SIS decommissioning | Phase 16 — decommissioning |
Scope of this table. It covers Clauses 8–18 only. IEC 61511-1’s earlier clauses — management of functional safety, the safety lifecycle structure itself, and verification — and its documentation requirements apply across all of the above and are not mapped here. Do not read an absence from this table as an absence from the standard.
Two evidence routes for SIS hardware
This is the practical difference between the two standards, and the point where the previous version of this page was wrong. IEC 61511-1 recognises two distinct routes for justifying that a device is suitable for use in a SIF at a given integrity level. They are not interchangeable, and one does not substitute for the other.
Route 1 — prior use
The user justifies the device from its documented history of operation in comparable service. The evidence is held by the user (or assembled by them from operator and manufacturer records), and it is about the specific device revision in conditions comparable to the intended application. The provisions sit within Clause 11, SIS design and engineering; check the exact sub-clause against your edition rather than citing one from memory or from an older edition.
Typically at issue in such a claim:
- Operating history of sufficient volume and duration to mean something statistically
- Service conditions in the record that are genuinely comparable to the intended application — process fluid, temperature, vibration, contamination, duty
- Failure records that were actually collected and reviewed, not assumed
- Configuration and revision control, so that the device being installed is the same device the record describes
- Assessment of any systematic faults revealed by that history
Route 2 — developed and assessed under IEC 61508
The device is developed and assessed against IEC 61508 — hardware under Part 2, embedded software under Part 3 — producing a systematic capability claim, failure-rate and diagnostic data, and a safety manual stating the conditions under which the device may be used. This evidence is produced by the developer, before the device reaches any particular plant.
What an FMEDA or a safety manual does and does not establish
An FMEDA can support failure-rate and diagnostic-coverage claims. A safety manual can state the constraints on how a device may be applied — configuration limits, proof-test requirements, the assumptions the failure data depends on. Both are legitimate and often essential inputs.
Neither, by itself, establishes a prior-use claim. An FMEDA is an analysis of a design; a safety manual is a set of use conditions. Neither is a record of the device having operated in comparable service, which is what a prior-use argument rests on. The inverse also holds: an operating-history record does not supply the failure-mode analysis, so it does not replace an FMEDA where one is needed. The two routes answer different questions, and evidence for one is not evidence for the other.
Correction note. An earlier version of this page stated that vendor-supplied FMEDA data and safety manuals “support the prior use claim”, and listed absence of an FMEDA as a reason prior use is unavailable. Both statements conflated the two routes and have been removed.
Architecture and integrity — interacting requirements, not a lookup
An earlier version of this page carried a table that paired SIL targets with fixed voting architectures and with fixed safe-failure-fraction thresholds. That table has been removed. It presented as a recipe what both standards treat as a set of interacting requirements resolved by the designer for a specific subsystem, and it was not a faithful account of either standard’s provisions.
What actually interacts when a subsystem architecture is settled:
- Hardware fault tolerance (HFT) — how many faults the subsystem tolerates while still performing the safety function. Voting arrangements are one way of realising a given HFT, not a synonym for it.
- Diagnostics — diagnostic coverage, and what the system does when a diagnostic detects a fault, which changes both the dangerous-undetected failure rate and the fault-reaction behaviour.
- Safe failure fraction and subsystem type — in IEC 61508-2, the constraints depend on whether all failure modes of the subsystem are well defined and quantifiable (Type A) or not (Type B), and Part 2 offers more than one route to satisfying them.
- Systematic capability — a separate question from random hardware failure, not addressed by adding channels.
- PFDavg for the whole safety instrumented function — sensors, logic solver, and final elements together, with the proof-test interval and proof-test coverage. Final elements commonly dominate.
- Common-cause failure — redundant channels sharing a cause, a process connection, a power supply, or a design defect do not deliver the fault tolerance the arrangement suggests on a drawing.
- Which evidence route the hardware sits on — prior use or IEC 61508 assessment, per the section above.
Because these interact, the architecture is an output of the design and verification work, not an input read off a table. IEC 61511-1 Clause 11 sets minimum fault-tolerance provisions with conditions attached; IEC 61508-2 sets architectural constraints with their own routes and conditions. Both are read from the governing edition for the specific subsystem in hand — including the conditions under which a stated minimum may differ. A generic web page is not a safe substitute for either.
SIL comes from the risk assessment, not from the equipment type
An earlier version of this page listed “typical process applications” against each SIL — for example associating emergency shutdown, fire and gas, or high-integrity pressure protection with a particular SIL band. That column has been removed, and no equivalent appears anywhere on this page.
The integrity target for a safety instrumented function is an output of the hazard and risk assessment and the allocation step (IEC 61511-1 Clauses 8–9) for that specific scenario: the consequence, the initiating-event frequency, the other independent protection layers credited, and the tolerable risk criteria the organisation or jurisdiction has set. The same category of equipment protecting different scenarios can carry different targets, and naming an application type is not a determination.
Presenting an equipment type or a hazard category as implying a SIL invites the target to be assumed rather than derived, which is the failure mode this section exists to prevent.
Certification and third-party assessment
Language around “SIL certification” is loose in the market, and the distinctions matter when assembling a safety case.
| Distinction | What it means in practice |
|---|---|
| Conformity vs. certification | Conforming to a standard and holding a certificate from an assessment body are different things. A certificate is one form of evidence of conformity; it is not the only one, and it is not itself the requirement. |
| What a certificate covers | A product certificate is bounded by the scheme it was issued under, the edition assessed, the stated systematic capability, and the conditions in the accompanying safety manual. Use outside those conditions is outside the certificate. |
| Where the obligation comes from | Whether third-party assessment is required at all is a matter of jurisdiction, the applicable regulatory regime, the owner’s specification, and the operating company’s functional safety management arrangements — not something either standard settles universally. Confirm it for your project and site. |
| Component certificate ≠ SIF integrity | A certificate on a sensor, logic solver, or final element does not establish that a safety instrumented function meets its target. That comes from the SIF-level verification against the SRS, including proof-test interval and coverage. |
| Who typically holds what | Device and logic-solver developers usually hold IEC 61508 assessment evidence for their products. Owner-operators and integrators hold the IEC 61511 lifecycle evidence — risk assessment, SRS, design verification, validation, and operating records. |
Assessment bodies are named on certificates by scheme; this page does not endorse or rank any of them, and a body’s name on a certificate does not extend the certificate’s scope.
When IEC 61508 is reached from IEC 61511 work
These are the situations that commonly route a process SIS project back to the foundation standard. Treat them as prompts to check, not as a closed list.
- A device or subsystem is being developed rather than selected — custom or modified hardware, or embedded software written for the safety function. This work sits under IEC 61508-2 and -3, and is normally the developer’s, not the plant’s.
- Neither evidence route is satisfied by what is available — no adequate comparable-service history, and no IEC 61508 assessment behind the device. Something has to change: a different device, a different architecture, or evidence that does not yet exist.
- Novel technology in the safety function — where the service history that a prior-use argument would rest on does not exist yet.
- The governing specification requires it — an owner’s specification, a regulator, or a project’s functional safety management plan may call for direct IEC 61508 assessment regardless of what would otherwise be sufficient.
- The application falls outside the process-sector scope of IEC 61511 — including integrity targets the process-sector standard routes elsewhere, and safety-related systems that are not process SIS.
Corpus Status
| Topic | Standards | Corpus Status |
|---|---|---|
| Functional safety foundation — framework, hardware, software, lifecycle | IEC 61508 (4 files) | Reviewed |
| Process SIS framework and lifecycle overview | IEC 61511 (4 files) | Reviewed |
| SIL determination methods — LOPA, risk graph, fault tree | IEC 61511 | Reviewed |
| Clause-by-clause notes for the full IEC 61511-1:2016 structure | IEC 61511 | Partial coverage — the corpus holds framework, hazard/risk assessment, design, and operation notes; not every clause has its own note |
| Certification schemes and third-party assessment rules | External to both corpora | Out of scope for this corpus |
Practical summary
- Working on a process SIS at a plant: work through IEC 61511-1 Clauses 8–18, and be explicit about which evidence route each device sits on.
- Developing a device or subsystem for use in safety functions: that work is IEC 61508, and the safety manual you produce becomes a constraint on everyone downstream.
- In either case, the integrity target comes from the risk assessment, the architecture comes from the design and verification work, and the clause numbers come from the edition in front of you — not from this page.
Related pages
This site is an independent educational reference for industrial automation standards. It paraphrases and organizes guidance in original language; it is not a substitute for the official published standards, professional engineering judgment, or legal review, and content has not been independently verified against current published editions.
Items marked Review pending await technical review against the identified edition. Items marked Planned have no reviewed source material behind them. Do not rely on this site for compliance determinations, safety-critical design decisions, or legal interpretation.