.. _fsd129: FSD129: The design and the methods used during the devlopment ############################################################# .. list-table:: Header :header-rows: 0 * - 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 ***************** .. contents:: .. _fsd129_general_requirements: 7.4.2 General requirements -------------------------- .. motivation:: Design :id: MOTIVATION_129_001 :status: PASS The design is created to meet the E/E/PE system safety requirements. See :ref:`FSD120` and :ref:`FSD304`. .. motivation:: Design :id: MOTIVATION_129_002 :status: PASS \a) see :ref:`fsd129_sil_architectural_constraints` and :ref:`fsd129_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 :ref:`fsd129_sil_architectural_constraints`. \d) See :ref:`fsd129_systematic_faults`. \e) Data communication failures described in 7.4.11 is covered in E/E/PE system safety requirements specification. See :ref:`FSD120` and :ref:`FSD114`. .. motivation:: Safety-related hardware and software :id: MOTIVATION_129_003 :status: PASS All hardware and software are considered safety related. See :ref:`FSD304`. .. motivation:: safety function SIL :id: MOTIVATION_129_004 :status: PASS 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. See :need:`SREQ_01A`. .. motivation:: Safety functions independence :id: MOTIVATION_129_005 :status: PASS Safety functions are equivalent to 14 independent I/O functions and two independent relay output functions. .. motivation:: FSD availability :id: MOTIVATION_129_006 :status: PASS All functional safety related documents, including the software safety requirements, are accessed by all people working in the project. .. motivation:: Requirements review :id: MOTIVATION_129_007 :status: PASS 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: * :need:`TEST_107_100`, * :need:`TEST_107_101`, * :need:`TEST_107_102`, .. motivation:: Techniques and measures :id: MOTIVATION_129_008 :status: PASS The techniques and measures used to satisfy the safety requirements are described in :ref:`FSD303`. .. motivation:: HW/SW interactions :id: MOTIVATION_129_009 :status: PASS See :ref:`FSD304`. The significant interaction between software and hardware is the control of the I/O and the relays. .. motivation:: subsystems :id: MOTIVATION_129_010 :status: PASS See :ref:`FSD124`, :ref:`FSD150`, and :ref:`FSD300`. The hardware and software are divided into subsystems (see :ref:`FSD304` and :ref:`FSD150`). The integration tests for each subsystem are specified under each subsystem section in :ref:`FSD120`. .. motivation:: Failure analysis :id: MOTIVATION_129_011 :status: PASS 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 :ref:`FSD002` for details on management of functional safety. .. motivation:: ASIC development :id: MOTIVATION_129_012 :status: N/A ASIC is not used in the design. .. _fsd129_element_synthesis: 7.4.3 Synthesis of elements to achieve the required systematic capability *************************************************************************** .. motivation:: Element partitioning not used :id: MOTIVATION_129_013 :status: N/A Element partitioning according to systematic capability is not used in the design. .. _fsd129_sil_architectural_constraints: 7.4.4 Requirements for hardware safety integrity architectural constraints *************************************************************************** .. motivation:: HFT/SFF :id: MOTIVATION_129_014 :status: PASS See HFT in :ref:`FSD304`. 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). .. motivation:: Type A and B subsystems :id: MOTIVATION_129_015 :status: PASS See :ref:`FSD120` and :ref:`FSD304`. .. motivation:: SFF estimation :id: MOTIVATION_129_016 :status: PASS 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. .. motivation:: SFF estimation :id: MOTIVATION_129_017 :status: N/A Not applicable as MTTR=0, see :need:`MOTIVATION_129_040`. .. motivation:: SIL :id: MOTIVATION_129_018 :status: PASS \1) The subsystems are specified :ref:`FSD304` \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. .. motivation:: SIL :id: MOTIVATION_129_019 :status: N/A \1) - \3) not applicable as requirement 7.4.4.2.1 is followed. .. motivation:: 7.4.4.2.3 :id: MOTIVATION_129_020 :status: PASS 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. .. motivation:: 7.4.4.2.4 :id: MOTIVATION_129_021 :status: PASS 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 :need:`MOTIVATION_129_047` and RISE Hardware evaluation report for details. .. motivation:: 7.4.4.3.1 :id: MOTIVATION_129_022 :status: PASS Only option \b) is applicable. Route 2H is not applied. Hardware fault tolerance for each subsystem is specified in :need:`MOTIVATION_129_031` and :need:`MOTIVATION_129_033`. .. motivation:: 7.4.4.3.2 :id: MOTIVATION_129_023 :status: N/A Not applicable: alternative architecture with reduced HFT not implemented. .. motivation:: 7.4.4.3.3 :id: MOTIVATION_129_024 :status: N/A Not applicable: route 1 used. .. motivation:: 7.4.4.3.4 :id: MOTIVATION_129_025 :status: PASS None of the elements have a diagnostic coverage below 60%. Route 2H is not applied. .. _fsd129_random_hardware_failures: 7.4.5 Requirements for quantifying the effect of random hardware failures ************************************************************************** .. motivation:: 7.4.5.1 :id: MOTIVATION_129_026 :status: PASS For probability of dangerous failure per hour (PFHd), see FMEDA report. The target failure measure, see :ref:`FSD120`. .. motivation:: 7.4.5.2 :id: MOTIVATION_129_027 :status: PASS \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 .. motivation:: 7.4.5.3 :id: MOTIVATION_129_028 :status: N/A Not applicable: all relevant subsystems have a HFT greater than 0. See :ref:`FSD115`. .. motivation:: 7.4.5.4 :id: MOTIVATION_129_029 :status: N/A See :need:`MOTIVATION_501_003` and :need:`MOTIVATION_501_004`, which motivates maintenance. .. motivation:: 7.4.5.5 :id: MOTIVATION_129_030 :status: PASS Target SIL is achieved. .. _fsd129_systematic_faults: 7.4.6 Requirements for the avoidance of systematic faults ********************************************************* .. motivation:: 7.4.6.1 :id: MOTIVATION_129_031 :status: PASS See :ref:`FSD303`. .. motivation:: 7.4.6.2 :id: MOTIVATION_129_032 :status: PASS \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. .. motivation:: 7.4.6.3 :id: MOTIVATION_129_033 :status: PASS See :ref:`FSD120`. 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 .. motivation:: 7.4.6.4 :id: MOTIVATION_129_034 :status: PASS 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. .. motivation:: 7.4.6.5 :id: MOTIVATION_129_035 :status: PASS See integration tests in :ref:`FSD150` and :ref:`FSD124`. .. motivation:: 7.4.6.6 :id: MOTIVATION_129_036 :status: N/A Not applicable: only a component of an EUC. All activities are on the developer's premises. .. motivation:: 7.4.6.7 :id: MOTIVATION_129_037 :status: N/A Not applicable: ASIC not used. 7.4.7 Requirements for the control of systematic faults ********************************************************* .. motivation:: 7.4.7.1 :id: MOTIVATION_129_038 :status: PASS See table A16 in :ref:`FSD303`. .. motivation:: 7.4.7.2 :id: MOTIVATION_129_039 :status: PASS See table A17 in :ref:`FSD303`. .. motivation:: 7.4.7.3 :id: MOTIVATION_129_040 :status: PASS See table A18 in :ref:`FSD303`. 7.4.8 Requirements for system behaviour on detection of a fault **************************************************************** .. motivation:: 7.4.8.1 :id: MOTIVATION_129_041 :status: PASS 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. .. motivation:: 7.4.8.2 :id: MOTIVATION_129_042 :status: N/A Not applicable: low demand not used. .. motivation:: 7.4.8.3 :id: MOTIVATION_129_043 :status: PASS 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: * Power supply Hardware diagnostics: * CPU1 monitors the power supply to CPU2 * CPU2 monitors the power supply to CPU1 Occurrence of a dangerous fault: * Voltage supply to CPU1 exceeds the required voltage range * Voltage supply to CPU2 exceeds the required voltage range 7.4.9 Requirements for E/E/PE system implementation ********************************************************* .. motivation:: 7.4.9.1 :id: MOTIVATION_129_044 :status: PASS The implementation is verified during the validation tests and the review for the validation test report. See derived tests from design requirements (:ref:`FSD120`), and test reports in :ref:`FSD150` and :ref:`FSD124` and :ref:`FSD300`. .. motivation:: 7.4.9.2 :id: MOTIVATION_129_045 :status: PASS Requirements for subsystems defined in :ref:`FSD120`. .. motivation:: 7.4.9.3 :id: MOTIVATION_129_046 :status: PASS \a) See :need:`MOTIVATION_129_032`. \b) See :ref:`FSD202`. \c) See :need:`MOTIVATION_129_032`. \d) Not applicable. The project is small and with few people involved. \e) See :ref:`FSD107`. .. motivation:: 7.4.9.4 :id: MOTIVATION_129_047 :status: PASS \a) See :need:`MOTIVATION_129_027`. \b) See :need:`MOTIVATION_129_027`. \c) See :need:`MOTIVATION_129_027`. \d) See :need:`MOTIVATION_129_027`. \e) See :ref:`FSD202`. \f) Life time for the Safety Simplifier is set to 10 years (lifetime for separate subsystems are not estimated). \g) See :need:`MOTIVATION_129_027`. * Proof test interval: Once per year * Maintenance requirements: Once per year * Diagnostic test interval: Continuous \h) See :need:`MOTIVATION_129_027`. \i) Diagnostic test interval: Continuous \j) See :need:`MOTIVATION_129_027`. \k) MTTR = 0 since the EUC is not operational during reparation. \l) See :need:`MOTIVATION_129_027` and FMEDA report. \m) Hardware fault tolerances for the subsystems: See :ref:`FSD304`. .. csv-table:: Mission Profile :file: ../resources/tables/2_mot_7.4.9.4_mission_profile.csv :widths: 50 25 15 15 15 15 15 :header-rows: 2 .. csv-table:: Summary :file: ../resources/tables/2_mot_7.4.9.4_summary.csv :widths: 50 25 15 15 15 15 15 :header-rows: 1 .. [#f1] Continuous (i.e. the ratio of the diagnostic test rate to the demand rate equals or exceeds 100) .. [#f2] In this E/E/PES, the hardware used for implementing diagnostics is integrated with, and not separate from, the hardware implementing the safety related channels/elements and is thus indirectly covered in the failure analysis used as basis for the SFF-calculation. .. motivation:: 7.4.9.5 :id: MOTIVATION_129_048 :status: PASS Failure rates from a recognised industry source (IEC TR62380) have been used in the design FMEA. .. motivation:: 7.4.9.6 :id: MOTIVATION_129_049 :status: PASS User manuals for concerned products include a specific safety section describing the safety requirements. Applicable parts from annex D are included. See :ref:`FSD501`. .. motivation:: 7.4.9.7 :id: MOTIVATION_129_050 :status: PASS 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 ********************************************************* .. motivation:: 7.4.10.1 :id: MOTIVATION_129_051 :status: N/A Not applicable: No subsystems have been considered as proven in use. .. motivation:: 7.4.10.2 :id: MOTIVATION_129_052 :status: N/A Not applicable: See :need:`MOTIVATION_129_051`. .. motivation:: 7.4.10.3 :id: MOTIVATION_129_053 :status: N/A Not applicable: See :need:`MOTIVATION_129_051`. .. motivation:: 7.4.10.4 :id: MOTIVATION_129_054 :status: N/A Not applicable: See :need:`MOTIVATION_129_051`. .. motivation:: 7.4.10.5 :id: MOTIVATION_129_055 :status: N/A Not applicable: See :need:`MOTIVATION_129_051`. .. motivation:: 7.4.10.6 :id: MOTIVATION_129_056 :status: N/A Not applicable: See :need:`MOTIVATION_129_051`. .. motivation:: 7.4.10.7 :id: MOTIVATION_129_057 :status: PASS Not applicable: See :need:`MOTIVATION_129_051`. 7.4.11 Additional requirements for data communications ********************************************************* .. motivation:: 7.4.11.1 :id: MOTIVATION_129_058 :status: PASS Communication is done via black channels or white channels. All black channels are documented in :ref:`blch-summary`. White channels are part of the full FSA assessment as requirements. .. motivation:: 7.4.11.2 :id: MOTIVATION_129_059 :status: PASS The communication between CPUs is considered a white channel. See C2C requirements in :ref:`FSD120`. Revision History **************** .. list-table:: :header-rows: 0 * - 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.