.. _61508-3: 61508-3 ======= Not passed: :need_count:`'EN-61508-3' in tags and status!='PASS' and status!='N/A'` Passed: :need_count:`'EN-61508-3' in tags and status=='PASS'` N/A: :need_count:`'EN-61508-3' in tags and status=='N/A'` .. needtable:: :tags: EN-61508-3 :columns: id, title, status, derived :sort: lineno .. req:: EN-61508-3 clause 6.1: additional requirements for management of safety-related software :id: EN_61508_3_6_1 :tags: EN-61508-3 :derived: MOTIVATION_002_201 The requirements are as detailed in 6.2 of IEC 61508-1, with the following additional requirements. .. req:: EN-61508-3 clause 6.2.2: software procurement planning :id: EN_61508_3_6_2_2 :tags: EN-61508-3 :derived: MOTIVATION_002_202 The functional safety planning shall define the strategy for software procurement, development, integration, verification, validation and modification to the extent required by the safety integrity level of the safety functions implemented by the E/E/PE safety-related system. .. req:: EN-61508-3 clause 6.2.3: software configuration management :id: EN_61508_3_6_2_3 :tags: EN-61508-3 :derived: MOTIVATION_002_203 Software configuration management shall: \a) apply administrative and technical controls throughout the software safety lifecycle, in order to manage software changes and thus ensure that the specified requirements for safety-related software continue to be satisfied; \b) guarantee that all necessary operations have been carried out to demonstrate that the required software systematic capability has been achieved; \c) maintain accurately and with unique identification all configuration items which are necessary to meet the safety integrity requirements of the E/E/PE safety-related system. Configuration items include at least the following: safety analysis and requirements; software specification and design documents; software source code modules; test plans and results; verification documents; pre-existing software elements and packages which are to be incorporated into the E/E/PE safety-related system; all tools and development environments which are used to create or test, or carry out any action on, the software of the E/E/PE safety-related system; \d) apply change-control procedures: * to prevent unauthorized modifications; to document modification requests; * to analyse the impact of a proposed modification, and to approve or reject the request; * to document the details of, and the authorisation for, all approved modifications; * to establish configuration baseline at appropriate points in the software development, and to document the (partial) integration testing of the baseline; * to guarantee the composition of, and the building of, all software baselines (including the rebuilding of earlier baselines). \e) ensure that appropriate methods are implemented to load valid software elements and data correctly into the run-time system; \f) document the following information to permit a subsequent functional safety audit: configuration status, release status, the justification (taking account of the impact analysis) for and approval of all modifications, and the details of the modification; \g) formally document the release of safety-related software. Master copies of the software and all associated documentation and version of data in service shall be kept to permit maintenance and modification throughout the operational lifetime of the released software. .. req:: EN-61508-3 clause 7.1.2.1: specify software lifecycle :id: EN_61508_3_7_1_2_1 :tags: EN-61508-3 :derived: MOTIVATION_002_101 A safety lifecycle for the development of software shall be selected and specified during safety planning in accordance with Clause 6 of IEC 61508-1. .. req:: EN-61508 clause 7.1.2.2: specify software lifecycle :id: EN_61508_3_7_1_2_2 :tags: EN-61508-3 :derived: MOTIVATION_002_102 Any software lifecycle model may be used provided all the objectives and requirements of this clause are met. .. req:: EN-61508 clause 7.1.2.3: software lifecycle activities :id: EN_61508_3_7_1_2_3 :tags: EN-61508-3 :derived: MOTIVATION_002_103 Each phase of the software safety lifecycle shall be divided into elementary activities with the scope, inputs and outputs specified for each phase. .. req:: EN-61508-3 clause 7.1.2.4: V-model compability :id: EN_61508_3_7_1_2_4 :tags: EN-61508-3 :derived: MOTIVATION_002_104 Provided that the software safety lifecycle satisfies the requirements of Table 1, it is acceptable to tailor the V-model (see Figure 6) to take account of the safety integrity and the complexity of the project. .. req:: EN-61508-3 clause 7.1.2.5: safety lifecycle customisations :id: EN_61508_3_7_1_2_5 :tags: EN-61508-3 :derived: MOTIVATION_002_105 Any customisation of the software safety lifecycle shall be justified on the basis of functional safety. .. req:: EN-61508-3 clause 7.1.2.6: safety assurance procedures :id: EN_61508_3_7_1_2_6 :tags: EN-61508-3 :derived: MOTIVATION_002_106 Quality and safety assurance procedures shall be integrated into safety lifecycle activities. .. req:: EN-61508-3 clause 7.1.2.7: appropiate safety lifesycle techniques :id: EN_61508_3_7_1_2_7 :tags: EN-61508-3 :derived: MOTIVATION_002_107 For each lifecycle phase, appropriate techniques and measures shall be used. Annexes A and B provide a guide to the selection of techniques and measures, and references to IEC 61508-6 and IEC 61508-7. IEC 61508-6 and IEC 61508-7 give recommendations on specific techniques to achieve the properties required for systematic safety integrity. Selecting techniques from these recommendations does not guarantee by itself that the required safety integrity will be achieved. .. req:: EN-61508-3 clause 7.1.2.8: safety lifecycle documentation :id: EN_61508_3_7_1_2_8 :tags: EN-61508-3 :derived: MOTIVATION_002_107 The results of the activities in the software safety lifecycle shall be documented (see Clause 5). .. req:: EN-61508-3 clause 7.1.2.9: impact analysis procedure :id: EN_61508_3_7_1_2_9 :tags: EN-61508-3 :derived: MOTIVATION_002_109 If at any phase of the software safety lifecycle, a modification is required pertaining to an earlier lifecycle phase, then an impact analysis shall determine (1) which software modules are impacted, and (2) which earlier safety lifecycle activities shall be repeated. .. req:: EN-61508-3 clause 7.2.2.1: requirement specification :id: EN_61508_3_7_2_2_1 :tags: EN-61508-3 :derived: MOTIVATION_319_001 If the requirements for safety-related software have already been specified for the E/E/PE safety-related system (see Clause 7 of IEC 61508-2), then the specification of software safety requirements need not be repeated. .. req:: EN-61508-3 clause 7.2.2.2: requirement specification :id: EN_61508_3_7_2_2_2 :tags: EN-61508-3 :derived: MOTIVATION_319_002 The specification of the requirements for safety-related software shall be derived from the specified safety requirements of the E/E/PE safety-related system (see IEC 61508- 2, 7), and any requirements of safety planning (see Clause 6). This information shall be made available to the software developer. .. req:: EN-61508-3 clause 7.2.2.3: sufficent requirement specification for FSA :id: EN_61508_3_7_2_2_3 :tags: EN-61508-3 :derived: MOTIVATION_319_003 The specification of the requirements for safety-related software shall be sufficiently detailed to allow the design and implementation to achieve the required safety integrity (including any requirement for independence, see 7.4.3 of IEC 61508-2), and to allow an assessment of functional safety to be carried out. .. req:: EN-61508-3 clause 7.2.2.4: common cause failure analysis :id: EN_61508_3_7_2_2_4 :tags: EN-61508-3 :derived: MOTIVATION_319_004 In order to address independence, a suitable common cause failure analysis shall be carried out. Where credible failure mechanisms are identified, effective defensive measures shall be taken. .. req:: EN-61508-3 clause 7.2.2.5: adequate requirement specifications :id: EN_61508_3_7_2_2_5 :tags: EN-61508-3 :derived: MOTIVATION_319_005 The software developer shall evaluate the information in 7.2.2.2 to ensure that the requirements are adequately specified. In particular the software developer shall consider the following: \a) safety functions; \b) configuration or architecture of the system; \c) hardware safety integrity requirements (programmable electronics, sensors, and actuators); \d) software systematic capability requirements; \e) capacity and response time; \f) equipment and operator interfaces, including reasonably foreseeable misuse. .. req:: EN-61508-3 clause 7.2.2.6: safety requirements for EUC :id: EN_61508_3_7_2_2_6 :tags: EN-61508-3 :derived: MOTIVATION_319_006 If not already adequately defined in specified safety requirements of the E/E/PE safety-related system, all relevant modes of operation of the EUC, of the E/E/PE system, and of any equipment or system connected to the E/E/PE system shall be detailed in the specified requirements for safety-related software. .. req:: EN-61508-3 clause 7.2.2.7: document relevant constraints :id: EN_61508_3_7_2_2_7 :tags: EN-61508-3 :derived: MOTIVATION_319_007 The software safety requirements specification shall specify and document any safety-related or relevant constraints between the hardware and the software. .. req:: EN-61508-3 clause 7.2.2.8: considerations for increased complexity :id: EN_61508_3_7_2_2_8 :tags: EN-61508-3 :derived: MOTIVATION_319_008 To the extent required by the E/E/PE hardware architecture design, and considering the possible increase in complexity, the software safety requirements specification shall consider the following: \a) software self-monitoring (for examples see IEC 61508-7); \b) monitoring of the programmable electronics hardware, sensors, and actuators; \c) periodic testing of safety functions while the system is running; \d) enabling safety functions to be testable when the EUC is operational; \e) software functions to execute proof tests and all diagnostic tests in order to fulfil the safety integrity requirement of the E/E/PE safety-related system. .. req:: EN-61508-3 clause 7.2.2.9: identification for non-safety functions :id: EN_61508_3_7_2_2_9 :tags: EN-61508-3 :derived: MOTIVATION_319_009 When the E/E/PE safety-related system is required to perform non-safety functions, then the specified requirements for safety-related software shall clearly identify the non-safety functions. .. req:: EN-61508-3 clause 7.2.2.10: appropiate requirement specifications :id: EN_61508_3_7_2_2_10 :tags: EN-61508-3 :derived: MOTIVATION_319_010 The software safety requirements specification shall express the required safety properties of the product, but not of the project as this is covered by safety planning (see Clause 6 of 61508-1). With reference to 7.2.2.1 to 7.2.2.9, the following shall be specified as appropriate: \a) the requirements for the following software safety functions: #. functions that enable the EUC to achieve or maintain a safe state; #. functions related to the detection, annunciation and management of faults in the programmable electronics hardware; #. functions related to the detection, annunciation and management of sensor and actuators faults; #. functions related to the detection, annunciation and management of faults in the software itself (software self-monitoring); #. functions related to the periodic testing of safety functions on-line (i.e. in the intended operational environment); #. functions related to the periodic testing of safety functions off-line (i.e. in an environment where the EUC is not being relied upon for its safety function); #. functions that allow the PE system to be safely modified; #. interfaces to non safety-related functions; #. capacity and response time performance; #. interfaces between the software and the PE system; #. safety-related communications (see 7.4.11 of IEC 61508-2). \b) the requirements for the software systematic capability: #. the safety integrity level(s) for each of the functions in a) above; #. independence requirements between functions. .. req:: EN-61508-3 clause 7.2.2.11: safety requirement standards :id: EN_61508_3_7_2_2_11 :tags: EN-61508-3 :derived: MOTIVATION_319_011 Where software safety requirements are expressed or implemented by configuration data, the data shall be: \a) consistent with the system safety requirements; \b) expressed in terms of the permitted range and authorized combinations of its operational parameters; \c) defined in a manner which is compatible with the underlying software (for example sequence of execution, run time, data structures, etc.). .. req:: EN-61508-3 clause 7.2.2.12: consideration of peformance characteristics :id: EN_61508_3_7_2_2_12 :tags: EN-61508-3 :derived: MOTIVATION_319_012 Where data defines the interface between software and external systems, the following performance characteristics shall be considered in addition to 7.4.11 of IEC 61508-2: \a) the need for consistency in terms of data definitions; \b) invalid, out of range or untimely values; \c) response time and throughput, including maximum loading conditions; \d) best case and worst case execution time, and deadlock; \e) overflow and underflow of data storage capacity. .. req:: EN-61508-3 clause 7.2.2.13: operational parameters :id: EN_61508_3_7_2_2_13 :tags: EN-61508-3 :derived: MOTIVATION_319_013 Operational parameters shall be protected against: \a) invalid, out of range or untimely values; \b) unauthorized changes; \c) corruption. .. req:: EN-61508-3 clause 7.3.2.1: detailed planning :id: EN_61508_3_7_3_2_1 :tags: EN-61508-3 :derived: MOTIVATION_319_100 Planning shall be carried out to specify the steps, both procedural and technical, that will be used to demonstrate that the software satisfies its safety requirements. .. req:: EN-61508-3 clause 7.3.2.2: validation plan :id: EN_61508_3_7_3_2_2 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The validation plan for software aspects of system safety shall consider the following: \a) details of when the validation shall take place; \b) details of those who shall carry out the validation; \c) identification of the relevant modes of the EUC operation including: #. preparation for use including setting and adjustment; #. start up, teach, automatic, manual, semi-automatic, steady state operation; #. re-setting, shut down, maintenance; #. reasonably foreseeable abnormal conditions and reasonably foreseeable operator misuse. \d) identification of the safety-related software which needs to be validated for each mode of EUC operation before commissioning commences; \e) the technical strategy for the validation (for example analytical methods, statistical tests etc.); \f) in accordance with item e), the measures (techniques) and procedures that shall be used for confirming that each safety function conforms with the specified requirements for the safety functions, and the specified requirements for software systematic capability; \g) the required environment in which the validation activities are to take place (for example, for tests this could include calibrated tools and equipment); \h) the pass/fail criteria; \i) the policies and procedures for evaluating the results of the validation, particularly failures. .. req:: EN-61508-3 clause 7.3.2.3: validation specification :id: EN_61508_3_7_3_2_3 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The validation shall give a rationale for the chosen strategy. The technical strategy for the validation of safety-related software shall include the following information: \a) choice of manual or automated techniques or both; \b) choice of static or dynamic techniques or both; \c) choice of analytical or statistical techniques or both. \d) choice of acceptance criteria based on objective factors or expert judgment or both. .. req:: EN-61508-3 clause 7.3.2.4: validation plan confirmation :id: EN_61508_3_7_3_2_4 :tags: EN-61508-3 :derived: MOTIVATION_319_100 As part of the procedure for validating safety-related software aspects, the scope and contents of the validation plan for software aspects of system safety shall be agreed with the assessor or with a party representing the assessor, if required by the safety integrity level (see Clause 8 of IEC 61508-1). This procedure shall also make a statement concerning the presence of the assessor during testing. .. req:: EN-61508-3 clause 7.3.2.5: criteria for accomplishing software validation :id: EN_61508_3_7_3_2_5 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The pass/fail criteria for accomplishing software validation shall include: \a) the required input signals with their sequences and their values; \b) the anticipated output signals with their sequences and their values; and \c) other acceptance criteria, for example memory usage, timing and value tolerances. .. req:: EN-61508-3 clause 7.4.2.1: determination of responsibility :id: EN_61508_3_7_4_2_1 :tags: EN-61508-3 :derived: MOTIVATION_321_001 Depending on the nature of the software development, responsibility for conformance with 7.4 can rest with the supplier of a safety related programming environment (e.g. PLC supplier) alone, or with the user of that environment (e.g. the application software developer) alone, or with both. The division of responsibility shall be determined during safety planning (see Clause 6). .. req:: EN-61508-3 clause 7.4.2.2: design method requirements :id: EN_61508_3_7_4_2_2 :tags: EN-61508-3 :derived: MOTIVATION_321_002 In accordance with the required safety integrity level and the specific technical requirements of the safety function, the design method chosen shall possess features that facilitate: \a) abstraction, modularity and other features which control complexity; \b) the expression of: #. functionality; #. information flow between elements; #. sequencing and time related information; #. timing constraints; #. concurrency and synchronized access to shared resources; #. data structures and their properties; #. design assumptions and their dependencies; #. exception handling; #. design assumptions (pre-conditions, post-conditions, invariants); #. comments. \c) ability to represent several views of the design including structural and behavioural views; \d) comprehension by developers and others who need to understand the design; \e) verification and validation. .. req:: EN-61508-3 clause 7.4.2.3: designment considering testability :id: EN_61508_3_7_4_2_3 :tags: EN-61508-3 :derived: MOTIVATION_321_003 Testability and the capacity for safe modification shall be considered during the design activities in order to facilitate implementation of these properties in the final safety-related system. .. req:: EN-61508-3 clause 7.4.2.4: design method features :id: EN_61508_3_7_4_2_4 :tags: EN-61508-3 :derived: MOTIVATION_321_004 The design method chosen shall possess features that facilitate software modification. Such features include modularity, information hiding and encapsulation. .. req:: EN-61508-3 clause 7.4.2.5: design representations :id: EN_61508_3_7_4_2_5 :tags: EN-61508-3 :derived: MOTIVATION_321_005 The design representations shall be based on a notation which is unambiguously defined or restricted to unambiguously defined features. .. req:: EN-61508-3 clause 7.4.2.6: design simplification :id: EN_61508_3_7_4_2_6 :tags: EN-61508-3 :derived: MOTIVATION_321_006 As far as practicable the design shall keep the safety-related part of the software simple. .. req:: EN-61508-3 clause 7.4.2.7: design requirements :id: EN_61508_3_7_4_2_7 :tags: EN-61508-3 :derived: MOTIVATION_321_007 The software design shall include, commensurate with the required safety integrity level, self-monitoring of control flow and data flow. On failure detection, appropriate actions shall be taken. .. req:: EN-61508-3 clause 7.4.2.8: implementation of safety and non-safety functions :id: EN_61508_3_7_4_2_8 :tags: EN-61508-3 :derived: MOTIVATION_321_008 Where the software is to implement both safety and non-safety functions, then all of the software shall be treated as safety-related, unless adequate design measures ensure that the failures of non-safety functions cannot adversely affect safety functions. .. req:: EN-61508-3 clause 7.4.2.9: implementation of different safety integrity levels :id: EN_61508_3_7_4_2_9 :tags: EN-61508-3 :derived: MOTIVATION_321_009 Where the software is to implement safety functions of different safety integrity levels, then all of the software shall be treated as belonging to the highest safety integrity level, unless adequate independence between the safety functions of the different safety integrity levels can be shown in the design. It shall be demonstrated either (1) that independence is achieved by both in the spatial and temporal domains, or (2) that any violation of independence is controlled. The justification for independence shall be documented. .. req:: EN-61508-3 clause 7.4.2.10: systematic capability requirement :id: EN_61508_3_7_4_2_10 :tags: EN-61508-3 :derived: MOTIVATION_321_010 Where the systematic capability of a software element is lower than the safety integrity level of the safety function which the software element supports, the element shall be used in combination with other elements such that the systematic capability of the combination equals the safety integrity level of the safety function. .. req:: EN-61508-3 clause 7.4.2.11: requirement for 7.4.3 of IEC 61508-2 for safety function implementations :id: EN_61508_3_7_4_2_11 :tags: EN-61508-3 :derived: MOTIVATION_321_011 Where a safety function is implemented using a combination of software elements of known systematic capability, the systematic capability requirements of 7.4.3 of IEC 61508- 2, shall apply to the combination of elements. .. req:: EN-61508-3 clause 7.4.2.12: pre-existing software element implementation :id: EN_61508_3_7_4_2_12 :tags: EN-61508-3 :derived: MOTIVATION_321_012 Where a pre-existing software element is reused to implement all or part of a safety function, the element shall meet both requirements a) and b) below for systematic safety integrity: \a) meet the requirements of one of the following compliance routes: * Route 1S: compliant development. Compliance with the requirements of this standard for the avoidance and control of systematic faults in software; * Route 2S: proven in use. Provide evidence that the element is proven in use. See 7.4.10 of IEC 61508-2; * Route 3S:assessment of non-compliant development. Compliance with 7.4.2.13. \b) provide a safety manual (see Annex D of IEC 61508-2 and Annex D of this standard) that gives a sufficiently precise and complete description of the element to make possible an assessment of the integrity of a specific safety function that depends wholly or partly on the pre-existing software element. .. req:: EN-61508-3 clause 7.4.2.13: pre-existing software requirements :id: EN_61508_3_7_4_2_13 :tags: EN-61508-3 :derived: MOTIVATION_321_013 To comply with Route 3s a pre-existing software element shall meet all of the following requirements a) to i): \a) The software safety requirements specification for the element in its new application shall be documented to the same degree of precision as would be required by this standard for any safety related element of the same systematic capability. The software safety requirements specification shall cover the functional and safety behaviour as applicable to the element in its new application and as specified in 7.2. See Table A.1. \b) The justification for use of a software element shall provide evidence that the desirable safety properties specified in the referenced subclauses (i.e. 7.2.2, 7.4.3, 7.4.4, 7.4.5, 7.4.6, 7.4.7, 7.5.2, 7.7.2, 7.8.2, 7.9.2, and Clause 8) have been considered, taking account of the guidance in Annex C. \c) The element's design shall be documented to a degree of precision, sufficient to provide evidence of compliance with the requirement specification and the required systematic capability. See 7.4.3, 7.4.5 and 7.4.6, and Tables A.2 and A.4 of Annex A. \d) The evidence required in 7.4.2.13 a) and 7.4.2.13 b) shall cover the software's integration with the hardware. See 7.5 and Table A.6 of Annex A. \e) There shall be evidence that the element has been subject to verification and validation using a systematic approach with documented testing and review of all parts of the element's design and code. See 7.4.7, 7.4.8, 7.5, 7.7 and 7.9 and Tables A.5 to A.7 and A.9 of Annex A as well as related tables in Annex B. \f) Where the software element provides functions which are are not required in the safety related system, then evidence shall be provided that the unwanted functions will not prevent the E/E/PE system from meeting its safety requirements. \g) There shall be evidence that all credible failure mechanisms of the software element have been identified and that appropriate mitigation measures have been implemented. \h) The planning for use of the element shall identify the configuration of the software element, the software and hardware run-time environment and if necessary the configuration of the compilation / linking system. \i) The justification for use of the element shall be valid for only those applications which respect the assumptions made in the compliant item safety manual for the element (see Annex D of IEC 61508-2 and Annex D). .. req:: EN-61508-3 clause 7.4.2.14: appropiate application of data generation languages :id: EN_61508_3_7_4_2_14 :tags: EN-61508-3 :derived: MOTIVATION_321_014 This Subclause 7.4.2 shall, in so far as it is appropriate, apply to data and data generation languages. \a) Where a PE system consists of pre-existing functionality that is configured by data to meet specific application requirements, the design of the application software shall be commensurate with the degree of application configurability, pre-delivered existing functionality and complexity of the PE safety-related system. \b) Where the safety-related functionality of a PE system is determined significantly or predominantly by configuration data, appropriate techniques and measures shall be used to prevent the introduction of faults during the design, production, loading and modification of the configuration data and to ensure that the configuration data correctly states the application logic. \c) The specification of data structures shall be: \d) consistent with the functional requirements of the system, including the application data; \e) complete; \f) self consistent; \g) such that the data structures are protected against alteration or corruption. \h) Where a PE System consists of pre-existing functionality that is configured by data to meet specific application requirements, the configuration process itself shall be documented appropriately. .. req:: EN-61508-3 clause 7.4.3.1: documentation of responsibility :id: EN_61508_3_7_4_3_1 :tags: EN-61508-3 :derived: MOTIVATION_321_101 Depending on the nature of the software development, responsibility for conformance with 7.4.4 can rest with multiple parties. The division of responsibility shall be documented during safety planning (see Clause 6 of IEC 61508-1). .. req:: EN-61508-3 clause 7.4.3.2: specify software architecture design :id: EN_61508_3_7_4_3_2 :tags: EN-61508-3 :derived: MOTIVATION_321_102 The software architecture design shall be established by the software supplier and/or developer, and shall be detailed. The software architecture design shall: \a) select and justify (see 7.1.2.7) an integrated set of techniques and measures necessary during the software safety lifecycle phases to satisfy the software safety requirements specification at the required safety integrity level. These techniques and measures include software design strategies for both fault tolerance (consistent with the hardware) and fault avoidance, including (where appropriate) redundancy and diversity; \b) be based on a partitioning into elements/subsystems, for each of which the following information shall be provided: \c) whether the elements/subsystems have been previously verified, and if yes, their verification conditions; \d) whether each subsystem/element is safety-related or not; \e) software systematic capability of the subsystem/element. \f) determine all software/hardware interactions and evaluate and detail their significance; \g) use a notation to represent the architecture which is unambiguously defined or restricted to unambiguously defined features; \h) select the design features to be used for maintaining the safety integrity of all data. Such data may include plant input-output data, communications data, operator interface data, maintenance data and internal database data; \i) specify appropriate software architecture integration tests to ensure that the software architecture satisfies the software safety requirements specification at the required safety integrity level. .. req:: EN-61508-3 clause 7.4.3.3: documentation for changes from 7.4.3.2 :id: EN_61508_3_7_4_3_3 :tags: EN-61508-3 :derived: MOTIVATION_321_103 Any changes required to the E/E/PE System Safety Requirements Specification (see 7.2.2) after applying 7.4.3.2 shall be agreed with the E/E/PE developer and documented. .. req:: EN-61508-3 clause 7.4.4.1: support tool consideration :id: EN_61508_3_7_4_4_1 :tags: EN-61508-3 :derived: MOTIVATION_321_201 A software on-line support tool shall be considered to be a software element of the safety-related system .. req:: EN-61508-3 clause 7.4.4.2: off-line support tool requirement :id: EN_61508_3_7_4_4_2 :tags: EN-61508-3 :derived: MOTIVATION_321_202 Software off-line support tools shall be selected as a coherent part of the software development activities. .. req:: EN-61508-3 clause 7.4.4.3: specify off-line support tool :id: EN_61508_3_7_4_4_3 :tags: EN-61508-3 :derived: MOTIVATION_321_203 The selection of the off-line support tools shall be justified. .. req:: EN-61508-3 clause 7.4.4.4: off-line support tool documentation :id: EN_61508_3_7_4_4_4 :tags: EN-61508-3 :derived: MOTIVATION_321_204 All off-line support tools in classes T2 and T3 shall have a specification or product documentation which clearly defines the behaviour of the tool and any instructions or constraints on its use. See 7.1.2 for software development lifecycle requirements, and 3.2.11 of IEC 61508-4 for categories of software off-line support tool. .. req:: EN-61508-3 clause 7.4.4.5: assessment for offline support tools :id: EN_61508_3_7_4_4_5 :tags: EN-61508-3 :derived: MOTIVATION_321_205 An assessment shall be carried out for offline support tools in classes T2 and T3 to determine the level of reliance placed on the tools, and the potential failure mechanisms of the tools that may affect the executable software. Where such failure mechanisms are identified, appropriate mitigation measures shall be taken. .. req:: EN-61508-3 clause 7.4.4.6: evidence for each tool in class T3 :id: EN_61508_3_7_4_4_6 :tags: EN-61508-3 :derived: MOTIVATION_321_206 For each tool in class T3, evidence shall be available that the tool conforms to its specification or documentation. Evidence may be based on a suitable combination of history of successful use in similar environments and for similar applications (within the organisation or other organisations), and of tool validation as specified in 7.4.4.7. .. req:: EN-61508-3 clause 7.4.4.7: documentation of tool validation :id: EN_61508_3_7_4_4_7 :tags: EN-61508-3 :derived: MOTIVATION_321_207 The results of tool validation shall be documented covering the following results: \a) a chronological record of the validation activities; \b) the version of the tool product manual being used; \c) the tool functions being validated; \d) tools and equipment used; \e) the results of the validation activity; the documented results of validation shall state either that the software has passed the validation or the reasons for its failure; \f) test cases and their results for subsequent analysis; \g) discrepancies between expected and actual results. .. req:: EN-61508-3 clause 7.4.4.8: controlling failures of safety related system :id: EN_61508_3_7_4_4_8 :tags: EN-61508-3 :derived: MOTIVATION_321_208 Where the conformance evidence of 7.4.4.6 is unavailable, there shall be effective measures to control failures of the executable safety related system that result from faults that are attributable to the tool. .. req:: EN-61508-3 clause 7.4.4.9: verification of tools :id: EN_61508_3_7_4_4_9 :tags: EN-61508-3 :derived: MOTIVATION_321_209 The compatibility of the tools of an integrated toolset shall be verified. .. req:: EN-61508-3 clause 7.4.4.10: controlling failures :id: EN_61508_3_7_4_4_10 :tags: EN-61508-3 :derived: MOTIVATION_321_210 To the extent required by the safety integrity level, the software or design representation (including a programming language) selected shall: \a) have a translator which has been assessed for fitness for purpose including, where appropriate, assessment against the international or national standards; \b) use only defined language features; \c) match the characteristics of the application; \d) contain features that facilitate the detection of design or programming mistakes; \e) support features that match the design method. .. req:: EN-61508-3 clause 7.4.4.11: addressing shortcomings of 7.4.4.10 :id: EN_61508_3_7_4_4_11 :tags: EN-61508-3 :derived: MOTIVATION_321_211 Where 7.4.4.10 cannot be fully satisfied, the fitness for purpose of the language, and any additional measures which address any identified shortcomings of the language shall be justified. .. req:: EN-61508-3 clause 7.4.4.12: choice of programming languages :id: EN_61508_3_7_4_4_12 :tags: EN-61508-3 :derived: MOTIVATION_321_212 Programming languages for the development of all safety-related software shall be used according to a suitable programming language coding standard. .. req:: EN-61508-3 clause 7.4.4.13: programming code conventions and standards :id: EN_61508_3_7_4_4_13 :tags: EN-61508-3 :derived: MOTIVATION_321_213 A programming language coding standard shall specify good programming practice, proscribe unsafe language features (for example, undefined language features, unstructured designs, etc.), promote code understandability, facilitate verification and testing, and specify procedures for source code documentation. Where practicable, the following information shall be contained in the source code: \a) legal entity (for example company, author(s), etc.); \b) description; \c) inputs and outputs; \d) configuration management history .. req:: EN-61508-3 clause 7.4.4.14: development support tools for automatic code generation :id: EN_61508_3_7_4_4_14 :tags: EN-61508-3 :derived: MOTIVATION_321_214 Where automatic code generation or similar automatic translation takes place, the suitability of the automatic translator for safety-related system development shall be assessed at the point in the development lifecycle where development support tools are selected. .. req:: EN-61508-3 clause 7.4.4.15: configuration management for off-line support tools :id: EN_61508_3_7_4_4_15 :tags: EN-61508-3 :derived: MOTIVATION_321_215 Where off-line support tools of classes T2 and T3 generate items in the configuration baseline, configuration management shall ensure that information on the tools is recorded in the configuration baseline. This includes in particular: \a) the identification of the tool and its version; \b) the identification of the configuration baseline items for which the tool version has been used; \c) the way the tool was used (including the tool parameters, options and scripts selected) for each configuration baseline item. .. req:: EN-61508-3 clause 7.4.4.16: qualified versions for configuration management :id: EN_61508_3_7_4_4_16 :tags: EN-61508-3 :derived: MOTIVATION_321_216 Configuration management shall ensure that for tools in classes T2 and T3, only qualified versions are used. .. req:: EN-61508-3 clause 7.4.4.17: compatible tools for configuration management :id: EN_61508_3_7_4_4_17 :tags: EN-61508-3 :derived: MOTIVATION_321_217 Configuration management shall ensure that only tools compatible with each other and with the safety-related system are used. .. req:: EN-61508-3 clause 7.4.4.18: qualification of new off-line support tools versions :id: EN_61508_3_7_4_4_18 :tags: EN-61508-3 :derived: MOTIVATION_321_218 Each new version of off-line support tool shall be qualified. This qualification may rely on evidence provided for an earlier version if sufficient evidence is provided that: \a) the functional differences (if any) will not affect tool compatibility with the rest of the toolset; and \b) the new version is unlikely to contain significant new, unknown faults. .. req:: EN-61508-3 clause 7.4.4.19: documentation of responsibility for 7.4.4 :id: EN_61508_3_7_4_4_19 :tags: EN-61508-3 :derived: MOTIVATION_321_219 Depending on the nature of the software development, responsibility for conformance with 7.4.4 can rest with multiple parties. The division of responsibility shall be documented during safety planning (see Clause 6 of IEC 61508-1). .. req:: EN-61508-3 clause 7.4.5.1: documentation of responsibility for 7.4.5 :id: EN_61508_3_7_4_5_1 :tags: EN-61508-3 :derived: MOTIVATION_321_301 Depending on the nature of the software development, responsibility for conformance with 7.4.5 can rest with multiple parties. The division of responsibility shall be documented during safety planning (see Clause 6 of IEC 61508-1). .. req:: EN-61508-3 clause 7.4.5.2: requirement for available information :id: EN_61508_3_7_4_5_2 :tags: EN-61508-3 :derived: MOTIVATION_321_302 The following information shall be available prior to the start of detailed design: the specification of requirements for the E/E/PE safety related system; the software architecture design; the validation plan for software aspects of system safety. .. req:: EN-61508-3 clause 7.4.5.3: software production standards :id: EN_61508_3_7_4_5_3 :tags: EN-61508-3 :derived: MOTIVATION_321_303 The software shall be produced to achieve modularity, testability, and the capability for safe modification. .. req:: EN-61508-3 clause 7.4.5.4: partioning software modules :id: EN_61508_3_7_4_5_4 :tags: EN-61508-3 :derived: MOTIVATION_321_304 For each major element/subsystem in the software architecture design, further refinement of the design shall be based on a partitioning into software modules (i.e. the specification of the software system design). The design of each software module and the verification to be applied to each software module shall be specified. .. req:: EN-61508-3 clause 7.4.5.5: implementation of integration tests :id: EN_61508_3_7_4_5_5 :tags: EN-61508-3 :derived: MOTIVATION_321_305 Appropriate software system integration tests shall be specified to ensure that the software system satisfies the software safety requirements specification at the required safety integrity level. .. req:: EN-61508-3 clause 7.4.6.1: review for software code modules :id: EN_61508_3_7_4_6_1 :tags: EN-61508-3 :derived: MOTIVATION_321_401 Each module of software code shall be reviewed. Where the code is produced by an automatic tool, the requirements of 7.4.4 shall be met. Where the source code consists of reused pre-existing software, the requirements of 7.4.2 shall be met. .. req:: EN-61508-3 clause 7.4.7.1: verification of each software module :id: EN_61508_3_7_4_7_1 :tags: EN-61508-3 :derived: MOTIVATION_300_001 Each software module shall be verified as required by the software module test specification that was developed during software system design (see 7.4.5). .. req:: EN-61508-3 clause 7.4.7.2: verification of not producing unintended functions :id: EN_61508_3_7_4_7_2 :tags: EN-61508-3 :derived: MOTIVATION_300_002 This verification shall show whether or not each software module performs its intended function and does not perform unintended functions. .. req:: EN-61508-3 clause 7.4.7.3: documentation of software module results :id: EN_61508_3_7_4_7_3 :tags: EN-61508-3 :derived: MOTIVATION_300_003 The results of the software module testing shall be documented. .. req:: EN-61508-3 clause 7.4.7.4: proper procedure of non passable tests :id: EN_61508_3_7_4_7_4 :tags: EN-61508-3 :derived: MOTIVATION_300_004 The procedures for corrective action on not passing the test shall be specified. .. req:: EN-61508-3 clause 7.4.8.1: specification of integration tests :id: EN_61508_3_7_4_8_1 :tags: EN-61508-3 :derived: MOTIVATION_300_101 Software integration tests shall be specified during the design and development phase (see 7.4.5). .. req:: EN-61508-3 clause 7.4.8.2: integration test specification requirements :id: EN_61508_3_7_4_8_2 :tags: EN-61508-3 :derived: MOTIVATION_300_102 The software system integration test specification shall state the following: \a) the division of the software into manageable integration sets; \b) test cases and test data; \c) types of tests to be performed; \d) test environment, tools, configuration and programs; \e) test criteria on which the completion of the test will be judged; \f) procedures for corrective action on failure of test. .. req:: EN-61508-3 clause 7.4.8.3: software system integration test specification :id: EN_61508_3_7_4_8_3 :tags: EN-61508-3 :derived: MOTIVATION_300_103 The software shall be tested in accordance with the software integration tests specified in the software system integration test specification. These tests shall show that all software modules and software elements/subsystems interact correctly to perform their intended function and do not perform unintended functions. .. req:: EN-61508-3 clause 7.4.8.4: integration test documentation :id: EN_61508_3_7_4_8_4 :tags: EN-61508-3 :derived: MOTIVATION_300_104 The results of software integration testing shall be documented, stating the test results, and whether the objectives and the test criteria have been met. If there is a failed integration test, the reasons for the failure shall be documented. .. req:: EN-61508-3 clause 7.4.8.5: impact analysis for modifications durin software integration :id: EN_61508_3_7_4_8_5 :tags: EN-61508-3 :derived: MOTIVATION_300_105 During software integration, any modification to the software shall be subject to an impact analysis which shall determine all software modules impacted, and the necessary re-verification and re-design activities. .. req:: EN-61508-3 clause 7.5.2.1: integration test specification for compabiltiy :id: EN_61508_3_7_5_2_1 :tags: EN-61508-3 :derived: MOTIVATION_300_201 Integration tests shall be specified during the design and development phase (see 7.4.3) to ensure the compatibility of the hardware and software in the safety-related programmable electronics. .. req:: EN-61508-3 clause 7.5.2.2: integration test specification requirements :id: EN_61508_3_7_5_2_2 :tags: EN-61508-3 :derived: MOTIVATION_300_202 The software/PE integration test specification (hardware and software) shall state the following: \a) the split of the system into integration levels; \b) test cases and test data; \c) types of tests to be performed; \d) test environment including tools, support software and configuration description; \e) test criteria on which the completion of the test will be judged. .. req:: EN-61508-3 clause 7.5.2.3: clear distinction between developer and user activites :id: EN_61508_3_7_5_2_3 :tags: EN-61508-3 :derived: MOTIVATION_300_203 The software/PE integration test specification (hardware and software) shall distinguish between those activities which can be carried out by the developer on his premises and those that require access to the user's site. .. req:: EN-61508-3 clause 7.5.2.4: distinction requirements :id: EN_61508_3_7_5_2_4 :tags: EN-61508-3 :derived: MOTIVATION_300_204 The software/PE integration test specification (hardware and software) shall distinguish between the following activities: \a) merging of the software system on to the target programmable electronic hardware; \b) E/E/PE integration, i.e. adding interfaces such as sensors and actuators; \c) applying the E/E/PE safety-related system to the EUC. .. req:: EN-61508-3 clause 7.5.2.5: integration of software/PE integration test specification :id: EN_61508_3_7_5_2_5 :tags: EN-61508-3 :derived: MOTIVATION_300_205 The software shall be integrated with the safety-related programmable electronic hardware in accordance with the software/PE integration test specification (hardware and software). .. req:: EN-61508-3 clause 7.5.2.6: integration system impact analysis when required :id: EN_61508_3_7_5_2_6 :tags: EN-61508-3 :derived: MOTIVATION_300_206 During the integration testing of the safety-related programmable electronics (hardware and software), any change to the integrated system shall be subject to an impact analysis. The impact analysis shall determine all software modules impacted, and the necessary re-verification activities. .. req:: EN-61508-3 clause 7.5.2.7: test case documentation :id: EN_61508_3_7_5_2_7 :tags: EN-61508-3 :derived: MOTIVATION_300_207 Test cases and their expected results shall be documented for subsequent analysis. .. req:: EN-61508-3 clause 7.5.2.8: integration test documentation of test results and critera :id: EN_61508_3_7_5_2_8 :tags: EN-61508-3 :derived: MOTIVATION_300_208 The integration testing of the safety-related programmable electronics (hardware and software) shall be documented, stating the test results, and whether the objectives and the test criteria have been met. If there is a failure, the reasons for the failure shall be documented. Any resulting modification or change to the software shall be subject to an impact analysis which shall determine all software elements/modules impacted, and the necessary re-verification and re-design activities. .. req:: EN-61508-3 clause 7.7.2.1: repeating validation :id: EN_61508_3_7_7_2_1 :tags: EN-61508-3 :derived: MOTIVATION_319_100 If the compliance with the requirements for safety-related software has already been established in the safety validation planning for the E/E/PE safety-related system (see 7.7 of IEC 61508-2), then the validation need not be repeated. .. req:: EN-61508-3 clause 7.7.2.2: validation activities :id: EN_61508_3_7_7_2_2 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The validation activities shall be carried out as specified the in validation plan for software aspects of system safety. .. req:: EN-61508-3 clause 7.7.2.3: document division of responsibility for 7.7 :id: EN_61508_3_7_7_2_3 :tags: EN-61508-3 :derived: MOTIVATION_319_100 Depending on the nature of the software development, responsibility for conformance with 7.7 can rest with multiple parties. The division of responsibility shall be documented during safety planning (see Clause 6 of IEC 61508-1). .. req:: EN-61508-3 clause 7.7.2.4: documenting validation :id: EN_61508_3_7_7_2_4 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The results of validating the software aspects of system safety shall be documented. .. req:: EN-61508-3 clause 7.7.2.5: validation documentation results :id: EN_61508_3_7_7_2_5 :tags: EN-61508-3 :derived: MOTIVATION_319_100 For each safety function, software safety validation shall document the following results: \a) a chronological record of the validation activities that will permit the sequence of activities to be retraced; NOTE When recording test results, it is important to be able to retrace the sequence of activities. The emphasis of this requirement is on retracing a sequence of activities, and not on producing a timed/dated list of documents. \b) the version of the validation plan for software aspects of system safety (see 7.3) being used; \c) the safety function being validated (by test or analysis), together with reference to the validation plan for software aspects of system safety; \d) tools and equipment used together with calibration data; \e) the results of the validation activity; \f) discrepancies between expected and actual results. .. req:: EN-61508-3 clause 7.7.2.6: documentation of discrepancies :id: EN_61508_3_7_7_2_6 :tags: EN-61508-3 :derived: MOTIVATION_319_100 When discrepancies occur between expected and actual results, the analysis made and the decisions taken on whether to continue the validation, or to issue a change request and return to an earlier part of the development lifecycle, shall be documented as part of the results of validating the software aspects of system safety. .. req:: EN-61508-3 clause 7.7.2.7: documentation of discrepancies :id: EN_61508_3_7_7_2_7 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The validation of safety-related software aspects of system safety shall meet the following requirements: \a) testing shall be the main validation method for software; analysis, animation and modelling may be used to supplement the validation activities; \b) the software shall be exercised by simulation of: #. input signals present during normal operation; #. anticipated occurrences; #. undesired conditions requiring system action; \c) the supplier and/or developer (or the multiple parties responsible for compliance) shall make available the documented results of the validation of software aspects of system safety and all pertinent documentation to the system developer to enable his product to meet the requirements of IEC 61508-1 and IEC 61508-2. .. req:: EN-61508-3 clause 7.7.2.8: software tools :id: EN_61508_3_7_7_2_8 :tags: EN-61508-3 :derived: MOTIVATION_319_100 Software tools shall meet the requirements of 7.4.4. .. req:: EN-61508-3 clause 7.7.2.9: software tools :id: EN_61508_3_7_7_2_9 :tags: EN-61508-3 :derived: MOTIVATION_319_100 The results of the validation of safety-related software aspects of system safety shall meet the following requirements: \a) the tests shall show that all of the specified requirements for safety-related software (see 7.2) are correctly met and the software does not perform unintended functions; \b) test cases and their results shall be documented for subsequent analysis and independent assessment (see Clause 8 of IEC 61508-1) as required by the safety integrity level; \c) the documented results of validating the software aspects of system safety shall state either (1) that the software has passed the validation or (2) the reasons for not passing the validation. .. req:: EN-61508-3 clause 7.8.2.1: software modification procedures :id: EN_61508_3_7_8_2_1 :tags: EN-61508-3 :derived: MOTIVATION_300_301 Prior to carrying out any software modification, software modification procedures shall be made available (see 7.16 of IEC 61508-1). .. req:: EN-61508-3 clause 7.8.2.2: software modification request :id: EN_61508_3_7_8_2_2 :tags: EN-61508-3 :derived: MOTIVATION_300_302 A modification shall be initiated only on the issue of an authorized software modification request under the procedures specified during safety planning (see Clause 6) which details the following: \a) the hazards which may be affected; \b) the proposed modification; \c) the reasons for modification. .. req:: EN-61508-3 clause 7.8.2.3: analysis for software modification :id: EN_61508_3_7_8_2_3 :tags: EN-61508-3 :derived: MOTIVATION_300_303 An analysis shall be carried out on the impact of the proposed software modification on the functional safety of the E/E/PE safety-related system: \a) to determine whether or not a hazard and risk analysis is required; \b) to determine which software safety lifecycle phases will need to be repeated. .. req:: EN-61508-3 clause 7.8.2.4: documentation for 7.8.2.3 :id: EN_61508_3_7_8_2_4 :tags: EN-61508-3 :derived: MOTIVATION_300_304 The impact analysis results obtained in 7.8.2.3 shall be documented. .. req:: EN-61508-3 clause 7.8.2.5: software safety lifecycle for modifications :id: EN_61508_3_7_8_2_5 :tags: EN-61508-3 :derived: MOTIVATION_300_305 All modifications which have an impact on the functional safety of the E/E/PE safety-related system shall initiate a return to an appropriate phase of the software safety lifecycle. All subsequent phases shall then be carried out in accordance with the procedures specified for the specific phases in accordance with the requirements in this standard. Safety planning (see Clause 6) shall detail all subsequent activities. .. req:: EN-61508-3 clause 7.8.2.6: modification of safety-related software requirements :id: EN_61508_3_7_8_2_6 :tags: EN-61508-3 :derived: MOTIVATION_300_306 The safety planning for the modification of safety-related software shall meet the requirements given in Clause 6 of IEC 61508-1. In particular: \a) identification of staff and specification of their required competency; \b) detailed specification for the modification; \c) verification planning; \d) scope of revalidation and testing of the modification to the extent required by the safety integrity level. .. req:: EN-61508-3 clause 7.8.2.7: modification plan :id: EN_61508_3_7_8_2_7 :tags: EN-61508-3 :derived: MOTIVATION_300_307 Modification shall be carried out as planned. .. req:: EN-61508-3 clause 7.8.2.8: documentation of modification details :id: EN_61508_3_7_8_2_8 :tags: EN-61508-3 :derived: MOTIVATION_300_308 Details of all modifications shall be documented, including references to: \a) the modification/retrofit request; \b) the results of the impact analysis which assesses the impact of the proposed software modification on the functional safety, and the decisions taken with associated justifications; \c) software configuration management history; \d) deviation from normal operations and conditions; \e) all documented information affected by the modification activity. .. req:: EN-61508-3 clause 7.8.2.9: documentation of details of all modifications :id: EN_61508_3_7_8_2_9 :tags: EN-61508-3 :derived: MOTIVATION_300_309 Information on the details of all modifications shall be documented. The documentation shall include the re-verification and re-validation of data and results. .. req:: EN-61508-3 clause 7.8.2.10: modification dependencies :id: EN_61508_3_7_8_2_10 :tags: EN-61508-3 :derived: MOTIVATION_300_310 The assessment of the required modification or retrofit activity shall be dependent on the results of the impact analysis and the software systematic capability. .. req:: EN-61508-3 clause 7.9.2.1: software verification plan :id: EN_61508_3_7_9_2_1 :tags: EN-61508-3 :derived: MOTIVATION_322_001 The verification of software shall be planned (see 7.3) concurrently with the develop- ment, for each phase of the software safety lifecycle, and shall be documented. .. req:: EN-61508-3 clause 7.9.2.2: software verification planning requirements :id: EN_61508_3_7_9_2_2 :tags: EN-61508-3 :derived: MOTIVATION_322_002 The software verification planning shall refer to the criteria, techniques and tools to be used in the verification activities, and shall address: \a) the evaluation of the safety integrity requirements; \b) the selection and documentation of verification strategies, activities and techniques; \c) the selection and utilisation of verification tools (test harness, special test software, input/output simulators etc.); \d) the evaluation of verification results; \e) the corrective actions to be taken. .. req:: EN-61508-3 clause 7.9.2.3: verification plan :id: EN_61508_3_7_9_2_3 :tags: EN-61508-3 :derived: MOTIVATION_322_002 The software verification shall be performed as planned. .. req:: EN-61508-3 clause 7.9.2.4: documentation of evidence :id: EN_61508_3_7_9_2_4 :tags: EN-61508-3 :derived: MOTIVATION_322_001 Evidence shall be documented to show that the phase being verified has, in all respects, been satisfactorily completed. .. req:: EN-61508-3 clause 7.9.2.5: verification documentation requirements :id: EN_61508_3_7_9_2_5 :tags: EN-61508-3 :derived: MOTIVATION_322_002 After each verification, the verification documentation shall include: \a) identification of items to be verified; \b) identification of the information against which the verification has been done; \c) non-conformances. .. req:: EN-61508-3 clause 7.9.2.6: phase N requirements :id: EN_61508_3_7_9_2_6 :tags: EN-61508-3 :derived: MOTIVATION_322_003 All essential information from phase N of the software safety lifecycle needed for the correct execution of the next phase N+1 shall be available and shall be verified. Outputs from phase N include: \a) adequacy of the specification, design, or code in phase N for: #. functionality; #. safety integrity, performance and other requirements of safety planning (see Clause 6); #. readability by the development team; #. testability for further verification; #. safe modification to permit further evolution; \b) adequacy of the validation planning and/or tests specified for phase N for specifying and describing the design of phase N; \c) check for incompatibilities between: #. the tests specified in phase N, and the tests specified in the previous phase N-1; #. the outputs within phase N. .. req:: EN-61508-3 clause 7.9.2.7: software development lifecycle verification activities :id: EN_61508_3_7_9_2_7 :tags: EN-61508-3 :derived: TEST_322_001 Subject to the choice of software development lifecycle (see 7.1), the following verification activities shall be performed: \a) verification of software safety requirements; \b) verification of software architecture; \c) verification of software system design; \d) verification of software module design; \e) verification of code; \f) verification of data; \g) verification of timing performance; \h) software module testing (see 7.4.7); \i) software integration testing (see 7.4.8); \j) programmable electronics integration testing (see 7.5); \k) software aspects of system safety validation (see 7.7). .. req:: EN-61508-3 clause 7.9.2.8: software verification requirements between phases :id: EN_61508_3_7_9_2_8 :tags: EN-61508-3 :derived: TEST_322_002 Verification of software safety requirements: after the software safety requirements specification has been completed, and before the next phase of software design and development begins, verification shall: \a) consider whether the software safety requirements specification adequately fulfils the E/E/PE system safety requirements specification (see 7.10 of IEC 61508-1 and 7.2 of IEC 61508-2) for functionality, safety integrity, performance, and any other requirements of safety planning; \b) consider whether the validation plan for software aspects of system safety adequately fulfils the software safety requirements specification; \c) check for incompatibilities between: #. the software safety requirements specification, and the E/E/PE system safety requirements specification (see 7.10 of IEC 61508-1 and 7.2 of IEC 61508-2); #. the software safety requirements specification, and the validation plan for software aspects of system safety. .. req:: EN-61508-3 clause 7.9.2.9: requirements after the software architecture design has been completed :id: EN_61508_3_7_9_2_9 :tags: EN-61508-3 :derived: TEST_322_003 Verification of software architecture: after the software architecture design has been completed, verification shall: \a) consider whether the software architecture design adequately fulfils the software safety requirements specification; \b) consider whether the integration tests specified in the software architecture design are adequate; \c) consider whether the attributes of each major element/subsystem are adequate with reference to: #. feasibility of the safety performance required; #. testability for further verification; #. readability by the development and verification team; #. safe modification to permit further evolution. \d) check for incompatibilities between the following: #. the software architecture design, and the software safety requirements specification; #. the software architecture design and its integration tests; #. the software architecture design integration tests and the validation plan for software aspects of system safety. .. req:: EN-61508-3 clause 7.9.2.10: requirements after the software system design has been completed :id: EN_61508_3_7_9_2_10 :tags: EN-61508-3 :derived: TEST_322_004 Verification of software system design: after the software system design has been completed, verification shall: \a) consider whether the software system design (see 7.4.5) adequately fulfils the software architecture design; \b) consider whether the specified tests of the software system integration (see 7.4.5) adequately fulfil the software system design (see 7.4.5); \c) consider whether the attributes of each major element of the software system design specification (see 7.4.5) are adequate with reference to: #. feasibility of the safety performance required; #. testability for further verification; #. readability by the development and verification team; #. safe modification to permit further evolution. \d) check for incompatibilities between: #. the software system design specification (see 7.4.5), and the software architecture design; #. the software system design specification (see 7.4.5), and the software system integration test specification (see.4.5); #. the tests required by the software system integration test specification (see 7.4.5) and the software architecture integration test specification (see 7.4.3). .. req:: EN-61508-3 clause 7.9.2.11: software verification requirements after software module design :id: EN_61508_3_7_9_2_11 :tags: EN-61508-3 :derived: TEST_322_005 Verification of software module design: after the design of each software module has been completed, verification shall: \a) consider whether the software module design specification (see 7.4.5) adequately fulfils the software system design specification (see 7.4.5); \b) consider whether the software module test specification (see 7.4.5) is adequate for the software module design specification (see 7.4.5); \c) consider whether the attributes of each software module are adequate with reference to: #. feasibility of the safety performance required (see software safety requirements specification); #. testability for further verification; #. readability by the development and verification team; #. safe modification to permit further evolution. \d) check for incompatibilities between: #. the software module design specification (see 7.4.5), and the software system design specification (see 7.4.5); #. (for each software module) the software module design specification (see 7.4.5), and the software module test specification (see 7.4.5); #. the software module test specification (see 7.4.5), and the software system integration test specification (see 7.4.5). .. req:: EN-61508-3 clause 7.9.2.12: verification of code :id: EN_61508_3_7_9_2_12 :tags: EN-61508-3 :derived: TEST_322_006 Verification of code: the source code shall be verified by static methods to ensure conformance to the software module design specification (see 7.4.5), the required coding standards (see 7.4.4), and the validation plan for software aspects of system safety. .. req:: EN-61508-3 clause 7.9.2.13: verification of data :id: EN_61508_3_7_9_2_13 :tags: EN-61508-3 :derived: TEST_322_007 Verification of data. \a) The data structures shall be verified. \b) The application data shall be verified for: #. consistency with the data structures; #. completeness against the application requirements; #. compatibility with the underlying system software (for example, sequence of execution, run-time, etc.); and #. correctness of the data values. \c) All operational parameters shall be verified against the application requirements. \d) All plant interfaces and associated software (i.e. sensors and actuators and off-line interfaces: see 7.2.2.12) shall be verified for: #. detection of anticipated interface failures; #. tolerance to anticipated interface failures. \e) All communication interfaces and associated software shall be verified for an adequate level of: \a) The data structures shall be verified. \b) The application data shall be verified for: #. consistency with the data structures; #. completeness against the application requirements; #. compatibility with the underlying system software (for example, sequence of execution, run-time, etc.); and #. correctness of the data values. \c) All operational parameters shall be verified against the application requirements. \d) All plant interfaces and associated software (i.e. sensors and actuators and off-line interfaces: see 7.2.2.12) shall be verified for: #. detection of anticipated interface failures; #. tolerance to anticipated interface failures. \e) All communication interfaces and associated software shall be verified for an adequate level of: #. failure detection; #. protection against corruption; #. data validation. .. req:: EN-61508-3 clause 7.9.2.14: verification of timing peformance :id: EN_61508_3_7_9_2_14 :tags: EN-61508-3 :derived: TEST_322_008 Verification of timing performance: predictability of behaviour in the time domain shall be verified.