.. _fsd002: FSD002: Management of functional safety ######################################## .. header .. list-table:: Header :header-rows: 0 * - Title - FSD002: Management of functional safety * - Current version - V3 * - Products - Safety Simplifier * - Requirements - 61508-1, clause 6.2.1-6.2.18 (Management of functional safety) 61508-1, clause 7.1.4.1-7.1.4.8 (Overall lifecycle safety requirements) 61508-2, clause 7.1.3.1-7.1.3.5 (E/E/PE system safety lifecycle requirements) 61508-3, clause 7.1.2.1-7.1.2.8 (Software safety lifecycle requirements) 61508-3, clause 6.2.1-6.2.3 (Additional requirements for management of safety-related software) * - Purpose - Specify the management, requirements and activities during E/E/PE system and software safety phases, to achieve functional safety * - Input - 61508-1 * - Output - Management requirements to be followed in all applicable phases of the project Table of contents ***************** .. contents:: :depth: 3 Management of functional safety ******************************** Motivations ====================== .. motivation:: Element safety function :id: MOTIVATION_002_001 :verifyer: RISE :status: N/A According to 61508, a safety function can only be implemented in a complete system which includes the subsystems sensor, logic and actuator. The Safety Simplifier is a component in a complete system and can therefore only provide the logic part. Thus, for further discussion, an element safety function is considered. Since the Safety Simplifier is only intended to be used as a part of a safety function, only the lifecycle activities 9 and 10 from 61508-1 figure 2 (E/E/PE system safety requirements specification and E/E/PE safety-related systems /Realisation) are applicable to the Safety Simplifier; the requirements in chapters 7.2 to 7.9 are not applicable. .. motivation:: General management :id: MOTIVATION_002_002 :verifyer: RISE :status: PASS Functional safety is achieved by: * Complying to 61508 during development of programmable electronic safety-related systems * Performing and complying to the Management of functional safety (this document, also part of 61508) * Educating all people involved in functional safety projects about 61508 * Assessing risks when using the product and performing risk analysis Functional safety is evaluated by: * Reviews/checks/audits on regular basis during all development phases, according to 61508. See reviews in :ref:`reviews-summary`. * Planning of all development phases * Validation and verification of the safety functions * Consulting a third party to guide and perform the functional safety assessment (FSA) For a high level overview of the functional safety development process see Appendix QMSDOC-1761341735-37 Functional safety development overview (available in SSP North Quality Management System). .. motivation:: Appointed responsible persons :id: MOTIVATION_002_003 :verifyer: RISE :status: PASS The following list is also cross checked with QMSDOC-1761341735-45, and the associated competence matrix. Identification of persons and departments responsible for applicable safety lifecycle phases, according to 61508-1 figure 2 and 61508-2 figure 2: * Phase 9 E/E/PE system safety requirements specification: * William Forsdal, SSP * Phase 10.1 E/E/PE system design requirements specification: * William Forsdal, SSP * Phase 10.2 E/E/PE system safety validation planning: * William Forsdal, SSP * Phase 10.3 E/E/PE system design and development: * Jesper Ribbe, AB Jier * Phase 10.4 E/E/PE system integration * Jesper Ribbe, AB Jier * Phase 10.5 E/E/PE system installation, commissioning, operation and maintenance procedures: * William Forsdal, SSP * Jesper Ribbe, AB Jier * Phase 10.6 E/E/PE system safety validation * William Forsdal, SSP * Jesper Ribbe, AB AB Jier According to 61508-3, figure 4, Software safety lifecycle: * Phase 10.1 Software safety requirements specification: * Jesper Ribbe, AB Jier * Reviewer: Mats Linger, SSP * Phase 10.2 Validation plan for software aspects of system safety * Jesper Ribbe, AB Jier * Reviewer: Mats Linger, SSP * Phase 10.3 Software design and development * Jesper Ribbe, AB Jier * Reviewer: Gary Ye, R&D, Jobtech * Phase 10.4 PE integration (hardware/software) * Jesper Ribbe, AB Jier * Gary Ye, R&D, Jobtech * Reviewer: Mats Linger, SSP * Phase 10.5 Software operation and maintenance procedures * Jesper Ribbe, AB Jier * Gary Ye, R&D, Jobtech * Reviewer: Mats Linger, SSP * Phase 10.6 Software aspects of system safety validation * Jesper Ribbe, AB Jier * Reviewer: Mats Linger, SSP The people involved in the E/E/PE system or software safety lifecycles have: * Basic knowledge of the overall safety lifecycle * Detailed knowledge of the specific safety lifecycles they are involved in * The project leader shall have a detailed knowledge of the overall safety lifecycle General documentation requirements: .. Don't know where to put "Software configuration management": //WF * Software configuration management shall comply with 61508-3, clause 6 (i.e. document configuration and release status, master copies shall be handled and stored separately to permit maintenance etc.). RISE is responsible for the functional safety assessment. .. test:: Responsible persons :id: TEST_002_003 :verifyer: SSP :derived: RESULT_002_003 Verify that all involved persons fulfil the requirements of :need:`MOTIVATION_002_003`. .. result:: Responsible persons :id: RESULT_002_003 :status: PASS All persons involved fulfil the requirements of :need:`MOTIVATION_002_003`. .. motivation:: recommendation resolution procedures :id: MOTIVATION_002_004 :status: PASS \a) Phase 3 not applicable for Safety Simplifier, however, general hazard and risk analyses are performed in activities where relevant. See QMSDOC-1761341735-35, and :ref:`fswp-summary`. \b) \c) \d) \e) The document QMSDOC-1761341735-35 (Modification of safety function, available in SSP North) explains the procedues for modifications of safety functions, including risk/hazard analysis and impact analysis. During development/implementation of a change, the change is documented in a work package (FSWP). See :ref:`fswp-summary`. Every phase in the project shall be planned in advance and the plan shall describe the sequence of work in the phase and also the outcome of the phase. Every phase shall end with an internal audit or review to identify if follow-up activities are needed. See reviews in :ref:`reviews-summary`. Meetings with a third party, RISE, performing the functional safety assessment (FSA) are held on regular basis. External audit or reviews with a third party can lead to follow-up activities. The same procedure as for the review applies. Each follow-up activity must be addressed to a person and a date for implementation and a new review must then be set. If the safety functions are involved in a follow-up activity a new impact analysis must be performed to guarantee that the safety functions are not changed. If a follow-up activity requires that all new updates shall be changed or removed, and it is easier to restart from an old version of a document, this is possible when using a version control system. \f) Appendix QMSDOC-1761341735-26 Communication for quality and delivery problems (available in SSP North Quality Management System) describes the communication for quality and delivery problems when product related quality problems are reported to SSP North. .. motivation:: hazard-management procedures :id: MOTIVATION_002_005 :status: PASS Under the condition that hazardous incidents are reported by customers, SSP North will act according to an established routine. Appendix QMSDOC-1761341735-27 Handle product issues and change requests (available in SSP North Quality Management System) describes the SSP North AB routines. Appendix QMSDOC-1761341735-26 Communication for quality and delivery problems describes the communication for quality and delivery problems when product related quality problems are reported to SSP North. Under the condition that systematic faults that can jeopardise the functional safety are reported by customers, SSP North will act according to an established routine. Appendix QMSDOC-1761341735-27 Handle product issues and change requests process for product issues and change requests describes the SSP North AB routines. .. motivation:: safety audits :id: MOTIVATION_002_006 :status: PASS Functional safety audits shall be performed like a regular review, but with focus on functional safety. The review shall be documented and followed up if necessary. Safety audits are held in accordance with the sub-phases in phase 10 of the lifecycle in 61508. .. motivation:: modification procedures :id: MOTIVATION_002_007 :status: PASS Modifications requiring changes to a finished development phase must be approved by the project leader. Modifications to a released product must be approved by the SSP North R&D manager. The document Appendix QMSDOC-1761341735-35 Modification of safety function (available in SSP North Quality Management System) is used to document this kind of modifications. For each modification request an impact analysis must be made. All steps in the modification procedure must be documented. The FSWP defintion is the tool used to comply with this. .. motivation:: hazard info maintenance procedures :id: MOTIVATION_002_008 :status: PASS User manuals shall contain information and warnings for potential hazards. Customers are responsible for reporting hazardous incidents to SSP North AB. .. motivation:: procedure development guidelines :id: MOTIVATION_002_009 :status: PASS A version control system is applied for version control of all functional safety documents created and maintained, in order to increase the control and overview in the overall document management. Benefits with a version control system are: * Avoiding the risk of working in an old version * All old versions are stored (together with version descriptions) * Easy to trace all updates and by whom and when they were made * Less risk when sharing documents (when several people work in the same project) .. motivation:: emergency services training :id: MOTIVATION_002_010 :status: PASS Not applicable, as the Safety Simplifier is only part of a safety function (see :need:`MOTIVATION_002_001`). .. motivation:: management and technical activities :id: MOTIVATION_002_011 :status: PASS \a) Techniques and measures are described in :ref:`fsd303`. \b) \c) See :need:`MOTIVATION_002_002`. .. old: .. The management and technical activities for each phase in the safety lifecycle are described in the concerned FSD documents. See also :need:`MOTIVATION_002_003`. .. motivation:: responsible persons competence :id: MOTIVATION_002_012 :status: PASS Competence maintained as new products with safety-related functions are developed on regular basis. Only experienced personnel are involved in the development of the product. See :need:`MOTIVATION_002_003`. .. motivation:: competence appropriateness consideration :id: MOTIVATION_002_013 :status: PASS Competence level is considered high, especially with experience from earlier projects involving FSA for 61508. See also :need:`MOTIVATION_002_003`. .. motivation:: QMS :id: MOTIVATION_002_014 :status: PASS The organisation manufacturing the SSP North AB products is required to follow the quality standard of ISO9000 and the concerned IPC standards for circuit boards and wiring harness. Reference the :download:`ISO9000 <../resources/JT/1. ISO9001-2015-certificate.pdf>` and :download:`ID Code process <../resources/JT/3. SSPN ID Code Control Process.pdf>` as production control documents. .. motivation:: activities relating to the management of functional safety :id: MOTIVATION_002_015 :status: PASS Covered in the overall 61508 FSA documentation. See also :need:`MOTIVATION_002_003`. The activities specified in this document are applied for the complete development lifecycle. Management activities specific for each phase in the safety lifecycle are described in the concerned FSD documents. .. motivation:: FSA :id: MOTIVATION_002_026 :derived: CHLST001-0001 Verifying the 6.2.2 to 6.2.15 requirements is done by completing the checklist :need:`CHLST_template001`. Overall safety lifecycle ========================== .. motivation:: management shall run in parallell with lifecycle :id: MOTIVATION_002_016 :status: PASS The Management of functional safety in 61508-1, clause 6, is applied during the E/E/PE system safety lifecycle phases. .. motivation:: lifecycle phases :id: MOTIVATION_002_017 :status: PASS See :need:`MOTIVATION_002_024`. Only lifecycle activities 9 and 10 from 61508-1 figure 2 are applicable to the Safety Simplifier. For each phase in the overall safety lifecycle that is applied, the requirements are met. Achievement of the requirements is controlled with checklists by the third party that is responsible for the functional safety assessment. .. motivation:: lifecycle phase activities, inputs and outputs :id: MOTIVATION_002_018 :derived: DOCREQ_02 Each phase has one or more corresponding documents which include the scope, activities, input and output of that phase. .. motivation:: outputs per phase as specified in table 1 :id: MOTIVATION_002_019 :status: PASS Table 1 in 61508-2 was followed when describing the purpose, input and output for each functional safety document that relates to a specific lifecycle phase. .. motivation:: lifecycle phase outputs meet requirements :id: MOTIVATION_002_020 :derived: TEST_002_020 The outputs for each phase meet the objectives and requirements for the overall safety lifecycle phase, unless something else is specified in the concerned document. .. test:: Lifecycle phase outputs meet requirements :id: TEST_002_020 :derived: RESULT_002_020 Verify that the output of each phase fulfils the objectives and requirements of each phase. .. result:: Lifecycle phase outputs meet requirements :id: RESULT_002_020 :status: PASS See :need:`MOTIVATION_002_024`. The documentation for each phase was reviewed and the output of each phase fulfils the objectives and requirements of each phase. .. motivation:: verification requirements :id: MOTIVATION_002_021 :derived: TEST_002_021 See :ref:`fsd107`. The verification requirements are met with verification plans for each phase, verification according to the plan, specified verification criteria, specified techniques and tools to be used, verification procedure to follow and verification reports for documentation use. .. test:: verification requirements :id: TEST_002_021 :derived: RESULT_002_021 Verify that the verification plan for each phase fulfil the requirements in 61508-1, clause 7.18. .. result:: verification requirements :id: RESULT_002_021 :status: PASS The verification plans for each phase fulfil the requirements in 61508-1, clause 7.18. See :ref:`fsd107` for the verification plan for each phase. E/E/PE system safety lifecycle requirements ================================================ .. motivation:: Lifecycle used :id: MOTIVATION_002_022 :status: PASS The E/E/PE system safety lifecycle specified in 61508-2, figure 2 is applied, as well as phase 9 in 61508-1 figure 2 (Safety requirements specification). ASIC not used in the design. See also :need:`MOTIVATION_002_001`. .. motivation:: Management shall run in parallell :id: MOTIVATION_002_023 :status: PASS The Management of functional safety in 61508-1, clause 6, is applied during the E/E/PE system safety lifecycle phases. See this document :ref:`fsd002`. .. motivation:: Realisation phases :id: MOTIVATION_002_024 :status: PASS Each phase in the realisation of the E/E/PE system safety lifecycle is divided into elementary activities, with scope, input, and output for each activity specified in the corresponding FSD document. As determined in :need:`MOTIVATION_002_001`, the following phases are considered: * Phase 9 E/E/PE system safety requirements specification: :ref:`fsd114`, * Phase 10.1 E/E/PE system design requirements specification: :ref:`fsd120`, * Phase 10.2 E/E/PE system safety validation planning: :ref:`FSD116`, * Phase 10.3 E/E/PE system design and development: :ref:`FSD129`, * Phase 10.4 E/E/PE system integration: :ref:`FSD305`, * Phase 10.5 E/E/PE system installation, commissioning, operation and maintenance procedures: see safety manual and :need:`MOTIVATION_002_001`, * Phase 10.6 E/E/PE system safety validation: :ref:`FSD133`. Software safety lifecycle requirements ======================================= .. motivation:: EN-61508-3 clause 7.1.2.1 :id: MOTIVATION_002_101 :status: PASS Example of phases and documentation in 7.1 is followed with one exception; due to the small size of the project the architecture and system design phases are merged, as suggested in 7.1.2.4 and 7.4.5. These are the resulting phases: #. Requirements #. System design #. Module design #. Coding and module testing #. Integration testing #. Software safety validation .. motivation:: EN-61508-3 clause 7.1.2.2 :id: MOTIVATION_002_102 :status: PASS The same procedure as for the E/E/PE system safety lifecycle applies. .. motivation:: EN-61508-3 clause 7.1.2.3 :id: MOTIVATION_002_103 :status: PASS The example in table 1, 61508-3 is followed. Model number for the products, requirements, purpose, input and output is specified in each functional safety document. .. motivation:: EN-61508-3 clause 7.1.2.4 :id: MOTIVATION_002_104 :status: PASS The V-model used, but without architectural level. Tailored V-model not applied. .. motivation:: EN-61508-3 clause 7.1.2.5 :id: MOTIVATION_002_105 :status: PASS The software safety lifecycle is used. .. motivation:: EN-61508-3 clause 7.1.2.6 :id: MOTIVATION_002_106 :status: PASS See general procedures for QA in QMSDOC-1761341735-26. .. motivation:: EN-61508-3 clause 7.1.2.7 :id: MOTIVATION_002_107 :status: PASS See :ref:`FSD303`. .. motivation:: EN-61508-3 clause 7.1.2.8 :id: MOTIVATION_002_108 :status: PASS Documentation is made according to 61508-1, clause 5. See :ref:`FSD001`. .. motivation:: EN-61508-3 clause 7.1.2.9 :id: MOTIVATION_002_109 :status: PASS The modification procedure is described in :ref:`fsd002` and in the document QMSDOC-1761341735-35 Modification of safety function (available in SSP North Quality Management System). The modification procedure is followed for all modifications to the software, including changes to requirements, design, code, and documentation. Additional requirements for management of safety-related software ===================================================================== .. motivation:: EN-61508-3 clause 6.2.1 :id: MOTIVATION_002_201 :status: PASS The requirements in 61508-3, clause 6.2 are followed, as described by the following motivations. .. motivation:: EN-61508-3 clause 6.2.2 :id: MOTIVATION_002_202 :status: PASS The safety software development process is adjusted to align with the guidelines and requirements in 61508, from earlier projects. .. motivation:: EN-61508-3 clause 6.2.3 :id: MOTIVATION_002_203 :status: PASS \a) All information that is to be saved is stored in the version control system (git). See :ref:`FSD001`. \b) Modifications requiring changes to a finished development phase must be approved by the project leader. Modifications to a released product must be approved by the R&D responsible. Software modifications are documented as work packages (FSWP). See :ref:`fswp-summary`. \c) For each modification request an analysis of the consequences of the modification is made. See :ref:`fswp-summary`. \d) All steps in the modification procedure are documented. See :ref:`fswp-summary`. \e) All software modules and their versions are tagged to the compiled software file. All software modules and software releases are tagged in the version control system. \f) Before any release all verification in the verification plan must be made. \g) All releases must be unchanging branches in the version control system. FSA ==== .. motivation:: FSA :id: MOTIVATION_002_025 :status: PASS The functional safety assessment (FSA) is performed by RISE, an independent third party. Revision History **************** .. list-table:: :header-rows: 1 * - Date - By - Version - Description * - 2018-05-31 - Mats Linger - V2 - Change of SP to RISE and Q numbers * - 2018-10-11 - Mats Linger - V3 - Corrections of spelling * - 2023-09-07 - Nils Odén - V4 - Copied over old document to new structure, no change in requirements. * - 2024-11-14 - Nils Odén - V5 - Appendix numbers updated with new QMS document ID's * - 2024-12-02 - William Forsdal - V6 - Changes: * Changed responsible persons (from Mats to William) for some responsibilities. * Split motivations and linked to motivations from 61508-1. * Moved motivations about documentation to FSD001. * Added tests. * - 2025-01-30 - William Forsdal - V6 - Changes: * Clarified and changed format of MOTIVATION_002_024. * - 2025-08-03 - Jesper Ribbe - V07 - Changes: * Added references to ISO certificate and production routines in MOTIVATION_002_014