A target SIL is not a wiring-diagram selector. It defines the required integrity of a complete safety function; the designer must allocate that requirement across the input, logic, and output subsystems, then prove that the chosen architecture, diagnostics, component reliability, and fault assumptions meet it. Before anything else, confirm the safety-function definition and the applicable edition of EN 62061.
Required design inputs
Do not select architecture A, B, C, or D from the target SIL alone. Obtain the following information from the machine manufacturer for every safety function:
| Input | Design decision it controls | Acceptance check |
|---|---|---|
| Hazard and required risk reduction | Target SIL for the complete function |
The requirement refers to a named safety function, not to the machine generally |
| Safe state | Output-device behavior after a demand or detected fault | The safe state is physically achievable under every operating mode |
| Demand and operating sequence | Sensor, logic, and actuator behavior | Reset, restart, and mode transitions are defined |
| Required response time | Maximum combined sensor, logic, output, and machine stopping time | The allowed time is stated and measurable |
| Type-C machine-standard requirements | Mandatory or preferred architecture for a specific machine | The selected circuit complies with the machine-specific requirement |
| Subsystem data | Failure calculation and architectural limits | Data covers every device in the safety path |
A panel builder receiving only “design to SIL” has an incomplete specification. Request the safety-function list, safe state, response-time requirement, operating modes, reset philosophy, and subsystem boundaries before producing a standard circuit.
Architecture comparison
The four architectures combine two independent design properties: hardware fault tolerance and diagnostics. Redundancy provides an alternate path after a fault; diagnostics detect faults and initiate a defined reaction. Neither property automatically replaces the other.
| Architecture | Hardware fault tolerance | Diagnostics | Principal limitation | Typical selection condition |
|---|---|---|---|---|
A |
No redundant fault-tolerant path | No dedicated diagnostic function | One dangerous channel failure can defeat the function | The calculated integrity and architectural constraint permit a simple channel |
B |
Redundant paths | No dedicated diagnostic function | Dangerous faults can remain hidden and accumulate | Redundancy is required and proof testing controls latent faults |
C |
No redundant fault-tolerant path | Diagnostic function included | A dangerous failure outside diagnostic coverage can defeat the function | Detection and a defined fault reaction provide the required integrity |
D |
Redundant paths | Diagnostic function included | Common-cause failures or ineffective diagnostics can defeat both paths | Both fault tolerance and diagnostic coverage are needed |
Use the architecture definitions and calculation rules from the edition of EN 62061 declared for the project. The letters describe a subsystem structure; they do not, by themselves, certify a safety function or guarantee a particular SIL.
Recommended selection method
Standardize the decision process, not a universal circuit for each SIL. A useful company library contains qualified subsystem patterns for recurring sensor, logic, and output arrangements. Each pattern records its assumptions, diagnostic behavior, permitted devices, failure data, proof-test requirements, response time, and validated application limits.
- Define the complete function. Record the initiating event, sensing devices, safety logic, final switching elements, actuators, safe state, reset behavior, and response-time limit. Do not move on until every device capable of preventing the safe state appears inside the boundary.
- Partition the function into subsystems. Use input, logic, and output boundaries that match the available component data and diagnostic implementation. Assigning a target to one device does not remove the need to evaluate the full chain.
- Identify the minimum fault behavior. Decide whether a single dangerous fault may immediately prevent the function. If it may not, select a fault-tolerant structure. Decide whether faults must be detected automatically; if so, provide diagnostics and a defined reaction.
- Compare architectures. Reject any option whose hardware fault tolerance or diagnostic behavior cannot meet the subsystem requirement. Apply any architecture prescribed by the relevant type-C machine standard.
-
Calculate the subsystem contribution. Use manufacturer failure data, mission assumptions, diagnostic coverage, proof-test provisions, common-cause treatment, and the calculation method required by
EN 62061. Record each source and assumption. - Combine the subsystem results. Confirm that the complete input-to-output safety function reaches the required integrity and response time. A high-integrity logic unit cannot compensate automatically for an unsuitable sensor or final element.
Electrical implementation checks
The schematic must implement the assumptions used in the calculation. A redundant drawing is not fault tolerant when both channels share a failure mechanism that removes both paths.
| Check | Question to answer | Required evidence |
|---|---|---|
| Channel independence | Can one short circuit, supply loss, terminal failure, or wiring error disable both channels? | Schematic and installation inspection |
| Diagnostic path | Which faults are detected, when are they detected, and what reaction follows? | Logic specification and fault-injection test |
| Final elements | Can welded, stuck, or non-switching elements be detected where the design requires detection? | Feedback-path design and test result |
| Common cause | Do channels share power, routing, environment, software, or mechanical actuation? | Documented separation and dependency review |
| Reset and restart | Can clearing a fault or restoring power initiate unexpected motion? | Mode-by-mode functional test |
| Response time | Does the complete function reach the safe state within the specified limit? | Measured worst-case result |
Diagnostic coverage must reflect real detectable faults, not merely the presence of a safety controller. Likewise, two contacts driven by one mechanism may retain common failure modes. Document any fault exclusion and its physical justification rather than using it to make a preferred architecture pass.
Calculation and documentation review
Architectural suitability and probabilistic performance are separate gates. First confirm that the architecture permits the claimed integrity under its fault-tolerance and diagnostic constraints. Then calculate the dangerous-failure contribution of each subsystem using the required data and equations. Both gates must pass.
Review the project file for component failure rates, diagnostic assumptions, test intervals, mission assumptions, common-cause measures, environmental limits, and response times. Where manufacturer subsystem data already includes internal architecture and diagnostics, use it only within its stated application conditions. Do not count an internal diagnostic twice in the overall calculation.
Trace every calculation entry back to a schematic reference and device record. If a value cannot be traced, obtain it from the component documentation or revise the design; inserting a typical value makes the verification non-reproducible.
Commissioning and fault verification
- Inspect the installed wiring against the validated schematic, including channel separation, power distribution, feedback circuits, and terminal assignments.
- Test the safety function from every initiating device and operating mode. Confirm the commanded safe state, reset behavior, and restart interlock.
- Inject each diagnosed fault identified in the design, one at a time. Confirm detection, annunciation, output reaction, and prevention of unsafe restart.
- For redundant architectures, disable each channel separately and verify that the remaining behavior matches the architectural assumptions. Test combinations required by the validation plan without creating an uncontrolled hazard.
- Measure the complete response time at the machine, including sensing, logic, output switching, and mechanical stopping. Compare the worst result with the specified limit.
- Restore all test links and devices, clear diagnostic records, repeat the normal safety-function test, and sign the results against the approved safety requirements.
Frequently asked questions
Can I choose an EN 62061 architecture from the SIL alone?
No. The target SIL must be evaluated together with subsystem failure data, hardware fault tolerance, diagnostics, common-cause measures, response time, and any type-C machine-standard requirement.
Does a two-channel circuit automatically meet the target SIL?
No. Two channels provide useful fault tolerance only when dependencies, latent faults, diagnostics, final-element behavior, and the complete safety-function calculation are addressed.
How do I verify the selected architecture on the machine?
Inject the faults claimed as detectable, disable redundant channels individually, confirm the defined safe-state and restart response, then measure the complete sensor-to-machine stopping time against the specified limit.