FSD129: The design and the methods used during the devlopment¶
Title |
FSD129: The design and the methods used during the development |
Products |
Safety Simplifier |
Requirements |
61508-2:2010, clause 7.4 |
Purpose |
Describe the design and the methods used during the development |
Input |
|
Output |
All paragraphs numbers are the same as the numbers in EN 61508-2. The standard is needed to read the requirements.
Table of contents¶
7.4.2 General requirements¶
The design is created to meet the E/E/PE system safety requirements. See FSD120: System design requirements specification and FSD304: System architecture description. |
a) see 7.4.4 Requirements for hardware safety integrity architectural constraints and 7.4.5 Requirements for quantifying the effect of random hardware failures. b) ICs with on-chip redundancy not used in the design. c) Route 1 applies; requirements for avoidance of systematic failures are fulfilled according to sections under 7.4.4 Requirements for hardware safety integrity architectural constraints. d) See 7.4.6 Requirements for the avoidance of systematic faults. e) Data communication failures described in 7.4.11 is covered in E/E/PE system safety requirements specification. See FSD120: System design requirements specification and FSD114: 61508-1 E/E/PE system safety requirements specification. |
All hardware and software are considered safety related. See FSD304: System architecture description. |
The safe functions are designed to fulfil the requirements for SIL3. The safe functions are considered a safety function from EN 61508:2010 perspective when integrated in a complete safety system. |
Safety functions are equivalent to 14 independent I/O functions and two independent relay output functions. |
All functional safety related documents, including the software safety requirements, are accessed by all people working in the project. |
The E/E/PE system and software safety requirements (FSD120) have been reviewed by the E/E/PE system developers. See results of verification activities in: |
The techniques and measures used to satisfy the safety requirements are described in FSD303: Techniques and measures. |
See FSD304: System architecture description. The significant interaction between software and hardware is the control of the I/O and the relays. |
See FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration, and FSD300: Software Module Tests. The hardware and software are divided into subsystems (see FSD304: System architecture description and FSD150: Validation tests of modes, power supply, and configuration). The integration tests for each subsystem are specified under each subsystem section in FSD120: System design requirements specification. |
The design is based on experience from past products in safety. The team has together 50 years of experience in safety design and safety standards. Over the years of safety products on the market, the design of safety products has been improved, e.g. more robust and reliable. All reported faults and flaws have been taken into account when making design updates. All safety related modifications have been implemented, tested and documented according to the procedures described in EN 61508:2010 and to equivalent procedures. See relevant QMS document QMSDOC-1761341735-27 describing handling of product issues and change requests. See also FSD002: Management of functional safety for details on management of functional safety. |
ASIC is not used in the design. |
7.4.3 Synthesis of elements to achieve the required systematic capability¶
Element partitioning according to systematic capability is not used in the design. |
7.4.4 Requirements for hardware safety integrity architectural constraints¶
See HFT in FSD304: System architecture description. The hardware safety integrity is calculated according to EN 61508:2010. The design is divided into subsystems. For every subsystem an SFF is calculated. The safety integrity level is determined by EN 61508-2:2010, table 2 and 3 (since both type A and type B subsystems are part of the design). |
Diagnostic test interval time for possible internal dangerous faults mentioned in 7.4.4.3.2 is less than the response time + 500 ms including reaching safe state. Flash memory is tested at every start-up of the unit. RAM memory is tested every program lap. |
Not applicable as MTTR=0, see 7.4.7.3 (MOTIVATION_129_040). |
1) The subsystems are specified FSD304: System architecture description 2) SFF for each subsystem has been calculated, see RISE FMEDA report. 3) The maximum safety integrity has been determined to SIL3 according to EN 61508-2:2010, table 2 and table 3. 4) See 5). 5) Lowest safety integrity level is SIL3. |
1) - 3) not applicable as requirement 7.4.4.2.1 is followed. |
Conditions for each subsystem are considered when determining the safety integrity level for the stop function. The safety functions implemented through a single channel. All subsystems in the design meet the requirements for safety integrity level 3, taking into account the number of channels for the subsystems and SFF values. |
Conditions for each subsystem are considered when determining the safety integrity level for the safe functions. No safety function is implemented through multiple channels, thus the resulting SIL is the same as the channel SIL. Also see 7.4.9.4 (MOTIVATION_129_047) and RISE Hardware evaluation report for details. |
Only option b) is applicable. Route 2H is not applied. Hardware fault tolerance for each subsystem is specified in 7.4.6.1 (MOTIVATION_129_031) and 7.4.6.3 (MOTIVATION_129_033). |
Not applicable: alternative architecture with reduced HFT not implemented. |
Not applicable: route 1 used. |
None of the elements have a diagnostic coverage below 60%. Route 2H is not applied. |
7.4.5 Requirements for quantifying the effect of random hardware failures¶
For probability of dangerous failure per hour (PFHd), see FMEDA report. The target failure measure, see FSD120: System design requirements specification. |
a) For probability of dangerous failure per hour (PFHd), see RISE FMEDA report. b) See a) c) For the rate of failure which could cause a dangerous failure, but is detected by diagnostic tests (λDD), see RISE FMEDA report. For the rate of failure which could cause a dangerous failure, but is not detected by diagnostic tests (λDU), see RISE FMEDA report. d) For common cause failures (λCCF), see RISE FMEDA report. e) For diagnostic coverage for the diagnostic tests (DCd), see RISE FMEDA report. Diagnostic test interval: Continuous f) Proof test interval: None (safety function faults will be detected by the operator or the system itself). g) Not applicable. h) Repair time for detected failures: None. The EUC is assumed to not be able to operate when replacing a defective receiver. i) Any detected internal hardware failures shall shut down the unit. This will force the operator to hand it in for service/repair and replace it with a working unit. j) See Techniques and measures. FSD303 |
Not applicable: all relevant subsystems have a HFT greater than 0. See FSD115-Element Safety Functions. |
See EN-61508-2 clause 7.6.2.3 (MOTIVATION_501_003) and EN-61508-2 clause 7.6.2.4 (MOTIVATION_501_004), which motivates maintenance. |
Target SIL is achieved. |
7.4.6 Requirements for the avoidance of systematic faults¶
a) The hardware design applies modularity, transparency and is fairly simple. b) Interfaces between subsystems and main functionality, see FSD304 c) Documentation according to EN 61508:2010 and by CAD-files, component lists and reviews. d) The validation tests are taken into account during the design work. All validation tests can be performed without any modifications of the test object. Common test equipment shall be used. For validation and verification details, see the documents E/E/PE system safety validation planning. When the products have been produced, test software is used to verify the overall functions of the units before being shipped to customers. The test software tests e.g. the radio module and the safety CPUs. Pass/fail criteria is implemented in the test software. |
See FSD120: System design requirements specification. A system start-up requires the receiver to be powered. At every start-up a start-up test is performed. The Safety Simplifiers is required to be power cycled at least once per year (See Safety manual). The start-up covers the test of the CPUs including flash memory test |
The CAD software warns whenever design constraints and requirements are not met (e.g. if a wire is routed to close to a via-hole etc.). Unwired threads are highlighted. |
See integration tests in FSD150: Validation tests of modes, power supply, and configuration and FSD124: GUI and Compiler function requirements, module tests and integration tests. |
Not applicable: only a component of an EUC. All activities are on the developer’s premises. |
Not applicable: ASIC not used. |
7.4.7 Requirements for the control of systematic faults¶
See table A16 in FSD303: Techniques and measures. |
See table A17 in FSD303: Techniques and measures. |
See table A18 in FSD303: Techniques and measures. |
7.4.8 Requirements for system behaviour on detection of a fault¶
The Safety Simplifier will enter a safe state if an internal dangerous fault in any internal subsystem with a hardware fault tolerance of more than zero is detected. When the failure is detected, the CPUs will turn off all outputs. The system has now entered a safe state. Detection of an internal dangerous fault will not result in isolation of the faulty part/subsystem and continued operation of the E/E/PE system. |
Not applicable: low demand not used. |
The Safety Simplifier will enter a safe state if an internal dangerous fault in any subsystem with a hardware fault tolerance of zero is detected. When the failure is detected, the CPUs turn off all the outputs. The system has now entered a safe state. Detection of an internal dangerous fault will not result in isolation of the faulty part/subsystem and continued operation of the E/E/PE system. Subsystems with a hardware fault tolerance of zero:
Hardware diagnostics:
Occurrence of a dangerous fault:
|
7.4.9 Requirements for E/E/PE system implementation¶
The implementation is verified during the validation tests and the review for the validation test report. See derived tests from design requirements (FSD120: System design requirements specification), and test reports in FSD150: Validation tests of modes, power supply, and configuration and FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD300: Software Module Tests. |
Requirements for subsystems defined in FSD120: System design requirements specification. |
a) See 7.4.6.2 (MOTIVATION_129_032). b) See FSD202: Mission Profile. c) See 7.4.6.2 (MOTIVATION_129_032). d) Not applicable. The project is small and with few people involved. e) See FSD107: System verification plan, validation test specifications and results. |
a) See 7.4.5.2 (MOTIVATION_129_027). b) See 7.4.5.2 (MOTIVATION_129_027). c) See 7.4.5.2 (MOTIVATION_129_027). d) See 7.4.5.2 (MOTIVATION_129_027). e) See FSD202: Mission Profile. f) Life time for the Safety Simplifier is set to 10 years (lifetime for separate subsystems are not estimated). g) See 7.4.5.2 (MOTIVATION_129_027).
h) See 7.4.5.2 (MOTIVATION_129_027). i) Diagnostic test interval: Continuous j) See 7.4.5.2 (MOTIVATION_129_027). k) MTTR = 0 since the EUC is not operational during reparation. l) See 7.4.5.2 (MOTIVATION_129_027) and FMEDA report. m) Hardware fault tolerances for the subsystems: See FSD304: System architecture description.
|
Failure rates from a recognised industry source (IEC TR62380) have been used in the design FMEA. |
User manuals for concerned products include a specific safety section describing the safety requirements. Applicable parts from annex D are included. See FSD501: Safety Manual Requirements. |
The safety-related information given in the user manual originates from the results of the FSA. If a modification of the safety function is made, that will affect the information given in the user manual, this will be covered by the SSP North procedure for modification of safety function. |
7.4.10 Requirements for proven in use elements¶
Not applicable: No subsystems have been considered as proven in use. |
Not applicable: See 7.4.10.1 (MOTIVATION_129_051). |
Not applicable: See 7.4.10.1 (MOTIVATION_129_051). |
Not applicable: See 7.4.10.1 (MOTIVATION_129_051). |
Not applicable: See 7.4.10.1 (MOTIVATION_129_051). |
Not applicable: See 7.4.10.1 (MOTIVATION_129_051). |
Not applicable: See 7.4.10.1 (MOTIVATION_129_051). |
7.4.11 Additional requirements for data communications¶
Communication is done via black channels or white channels. All black channels are documented in BLCH - Black Channels. White channels are part of the full FSA assessment as requirements. |
The communication between CPUs is considered a white channel. See C2C requirements in FSD120: System design requirements specification. |
Revision History¶
Date |
By |
Version |
Description |
2018-07-26 |
Mats Linger |
V1 |
Initial version |
2018-09-02 |
Mats Linger |
V2 |
References in 7.4.2.1 |
2025-06-10 |
WF |
V3 |
Updated for sphinx. |
2025-07-30 |
Jesper Ribbe |
V04 |
Added tables for mission profile and a summary in 7.4.9.4. Clarified MOTIVATION_129_021. |