61508-3¶
Not passed: 0
Passed: 101
N/A: 21
ID |
Title |
Status |
Derived |
|---|---|---|---|
EN-61508-3 clause 6.1: additional requirements for management of safety-related software |
PASS |
||
EN-61508-3 clause 6.2.2: software procurement planning |
PASS |
||
EN-61508-3 clause 6.2.3: software configuration management |
PASS |
||
EN-61508-3 clause 7.1.2.1: specify software lifecycle |
PASS |
||
EN-61508 clause 7.1.2.2: specify software lifecycle |
PASS |
||
EN-61508 clause 7.1.2.3: software lifecycle activities |
PASS |
||
EN-61508-3 clause 7.1.2.4: V-model compability |
PASS |
||
EN-61508-3 clause 7.1.2.5: safety lifecycle customisations |
PASS |
||
EN-61508-3 clause 7.1.2.6: safety assurance procedures |
PASS |
||
EN-61508-3 clause 7.1.2.7: appropiate safety lifesycle techniques |
PASS |
||
EN-61508-3 clause 7.1.2.8: safety lifecycle documentation |
PASS |
||
EN-61508-3 clause 7.1.2.9: impact analysis procedure |
PASS |
||
EN-61508-3 clause 7.2.2.1: requirement specification |
PASS |
||
EN-61508-3 clause 7.2.2.2: requirement specification |
PASS |
||
EN-61508-3 clause 7.2.2.3: sufficent requirement specification for FSA |
PASS |
||
EN-61508-3 clause 7.2.2.4: common cause failure analysis |
PASS |
||
EN-61508-3 clause 7.2.2.5: adequate requirement specifications |
PASS |
||
EN-61508-3 clause 7.2.2.6: safety requirements for EUC |
PASS |
||
EN-61508-3 clause 7.2.2.7: document relevant constraints |
PASS |
||
EN-61508-3 clause 7.2.2.8: considerations for increased complexity |
PASS |
||
EN-61508-3 clause 7.2.2.9: identification for non-safety functions |
PASS |
||
EN-61508-3 clause 7.2.2.10: appropiate requirement specifications |
PASS |
||
EN-61508-3 clause 7.2.2.11: safety requirement standards |
PASS |
||
EN-61508-3 clause 7.2.2.12: consideration of peformance characteristics |
PASS |
||
EN-61508-3 clause 7.2.2.13: operational parameters |
PASS |
||
EN-61508-3 clause 7.3.2.1: detailed planning |
N/A |
||
EN-61508-3 clause 7.3.2.2: validation plan |
N/A |
||
EN-61508-3 clause 7.3.2.3: validation specification |
N/A |
||
EN-61508-3 clause 7.3.2.4: validation plan confirmation |
N/A |
||
EN-61508-3 clause 7.3.2.5: criteria for accomplishing software validation |
N/A |
||
EN-61508-3 clause 7.4.2.1: determination of responsibility |
PASS |
||
EN-61508-3 clause 7.4.2.2: design method requirements |
PASS |
||
EN-61508-3 clause 7.4.2.3: designment considering testability |
PASS |
||
EN-61508-3 clause 7.4.2.4: design method features |
PASS |
||
EN-61508-3 clause 7.4.2.5: design representations |
PASS |
||
EN-61508-3 clause 7.4.2.6: design simplification |
PASS |
||
EN-61508-3 clause 7.4.2.7: design requirements |
PASS |
||
EN-61508-3 clause 7.4.2.8: implementation of safety and non-safety functions |
PASS |
||
EN-61508-3 clause 7.4.2.9: implementation of different safety integrity levels |
PASS |
||
EN-61508-3 clause 7.4.2.10: systematic capability requirement |
PASS |
||
EN-61508-3 clause 7.4.2.11: requirement for 7.4.3 of IEC 61508-2 for safety function implementations |
N/A |
||
EN-61508-3 clause 7.4.2.12: pre-existing software element implementation |
N/A |
||
EN-61508-3 clause 7.4.2.13: pre-existing software requirements |
N/A |
||
EN-61508-3 clause 7.4.2.14: appropiate application of data generation languages |
PASS |
||
EN-61508-3 clause 7.4.3.1: documentation of responsibility |
PASS |
||
EN-61508-3 clause 7.4.3.2: specify software architecture design |
PASS |
||
EN-61508-3 clause 7.4.3.3: documentation for changes from 7.4.3.2 |
PASS |
||
EN-61508-3 clause 7.4.4.1: support tool consideration |
N/A |
||
EN-61508-3 clause 7.4.4.2: off-line support tool requirement |
PASS |
||
EN-61508-3 clause 7.4.4.3: specify off-line support tool |
PASS |
||
EN-61508-3 clause 7.4.4.4: off-line support tool documentation |
PASS |
||
EN-61508-3 clause 7.4.4.5: assessment for offline support tools |
PASS |
||
EN-61508-3 clause 7.4.4.6: evidence for each tool in class T3 |
PASS |
||
EN-61508-3 clause 7.4.4.7: documentation of tool validation |
PASS |
||
EN-61508-3 clause 7.4.4.8: controlling failures of safety related system |
N/A |
||
EN-61508-3 clause 7.4.4.9: verification of tools |
PASS |
||
EN-61508-3 clause 7.4.4.10: controlling failures |
PASS |
||
EN-61508-3 clause 7.4.4.11: addressing shortcomings of 7.4.4.10 |
N/A |
||
EN-61508-3 clause 7.4.4.12: choice of programming languages |
PASS |
||
EN-61508-3 clause 7.4.4.13: programming code conventions and standards |
PASS |
||
EN-61508-3 clause 7.4.4.14: development support tools for automatic code generation |
PASS |
||
EN-61508-3 clause 7.4.4.15: configuration management for off-line support tools |
PASS |
||
EN-61508-3 clause 7.4.4.16: qualified versions for configuration management |
PASS |
||
EN-61508-3 clause 7.4.4.17: compatible tools for configuration management |
PASS |
||
EN-61508-3 clause 7.4.4.18: qualification of new off-line support tools versions |
PASS |
||
EN-61508-3 clause 7.4.4.19: documentation of responsibility for 7.4.4 |
PASS |
||
EN-61508-3 clause 7.4.5.1: documentation of responsibility for 7.4.5 |
PASS |
||
EN-61508-3 clause 7.4.5.2: requirement for available information |
PASS |
||
EN-61508-3 clause 7.4.5.3: software production standards |
PASS |
||
EN-61508-3 clause 7.4.5.4: partioning software modules |
PASS |
||
EN-61508-3 clause 7.4.5.5: implementation of integration tests |
PASS |
||
EN-61508-3 clause 7.4.6.1: review for software code modules |
PASS |
||
EN-61508-3 clause 7.4.7.1: verification of each software module |
PASS |
||
EN-61508-3 clause 7.4.7.2: verification of not producing unintended functions |
PASS |
||
EN-61508-3 clause 7.4.7.3: documentation of software module results |
PASS |
||
EN-61508-3 clause 7.4.7.4: proper procedure of non passable tests |
PASS |
||
EN-61508-3 clause 7.4.8.1: specification of integration tests |
PASS |
||
EN-61508-3 clause 7.4.8.2: integration test specification requirements |
PASS |
||
EN-61508-3 clause 7.4.8.3: software system integration test specification |
PASS |
||
EN-61508-3 clause 7.4.8.4: integration test documentation |
PASS |
||
EN-61508-3 clause 7.4.8.5: impact analysis for modifications durin software integration |
PASS |
||
EN-61508-3 clause 7.5.2.1: integration test specification for compabiltiy |
PASS |
||
EN-61508-3 clause 7.5.2.2: integration test specification requirements |
PASS |
||
EN-61508-3 clause 7.5.2.3: clear distinction between developer and user activites |
N/A |
||
EN-61508-3 clause 7.5.2.4: distinction requirements |
PASS |
||
EN-61508-3 clause 7.5.2.5: integration of software/PE integration test specification |
PASS |
||
EN-61508-3 clause 7.5.2.6: integration system impact analysis when required |
PASS |
||
EN-61508-3 clause 7.5.2.7: test case documentation |
PASS |
||
EN-61508-3 clause 7.5.2.8: integration test documentation of test results and critera |
PASS |
||
EN-61508-3 clause 7.7.2.1: repeating validation |
N/A |
||
EN-61508-3 clause 7.7.2.2: validation activities |
N/A |
||
EN-61508-3 clause 7.7.2.3: document division of responsibility for 7.7 |
N/A |
||
EN-61508-3 clause 7.7.2.4: documenting validation |
N/A |
||
EN-61508-3 clause 7.7.2.5: validation documentation results |
N/A |
||
EN-61508-3 clause 7.7.2.6: documentation of discrepancies |
N/A |
||
EN-61508-3 clause 7.7.2.7: documentation of discrepancies |
N/A |
||
EN-61508-3 clause 7.7.2.8: software tools |
N/A |
||
EN-61508-3 clause 7.7.2.9: software tools |
N/A |
||
EN-61508-3 clause 7.8.2.1: software modification procedures |
PASS |
||
EN-61508-3 clause 7.8.2.2: software modification request |
PASS |
||
EN-61508-3 clause 7.8.2.3: analysis for software modification |
PASS |
||
EN-61508-3 clause 7.8.2.4: documentation for 7.8.2.3 |
PASS |
||
EN-61508-3 clause 7.8.2.5: software safety lifecycle for modifications |
PASS |
||
EN-61508-3 clause 7.8.2.6: modification of safety-related software requirements |
PASS |
||
EN-61508-3 clause 7.8.2.7: modification plan |
PASS |
||
EN-61508-3 clause 7.8.2.8: documentation of modification details |
PASS |
||
EN-61508-3 clause 7.8.2.9: documentation of details of all modifications |
PASS |
||
EN-61508-3 clause 7.8.2.10: modification dependencies |
PASS |
||
EN-61508-3 clause 7.9.2.1: software verification plan |
PASS |
||
EN-61508-3 clause 7.9.2.2: software verification planning requirements |
PASS |
||
EN-61508-3 clause 7.9.2.3: verification plan |
PASS |
||
EN-61508-3 clause 7.9.2.4: documentation of evidence |
PASS |
||
EN-61508-3 clause 7.9.2.5: verification documentation requirements |
PASS |
||
EN-61508-3 clause 7.9.2.6: phase N requirements |
PASS |
||
EN-61508-3 clause 7.9.2.7: software development lifecycle verification activities |
PASS |
||
EN-61508-3 clause 7.9.2.8: software verification requirements between phases |
PASS |
||
EN-61508-3 clause 7.9.2.9: requirements after the software architecture design has been completed |
PASS |
||
EN-61508-3 clause 7.9.2.10: requirements after the software system design has been completed |
PASS |
||
EN-61508-3 clause 7.9.2.11: software verification requirements after software module design |
PASS |
||
EN-61508-3 clause 7.9.2.12: verification of code |
PASS |
||
EN-61508-3 clause 7.9.2.13: verification of data |
PASS |
||
EN-61508-3 clause 7.9.2.14: verification of timing peformance |
PASS |
Requirement: EN-61508-3 clause 6.1: additional requirements for management of safety-related software EN_61508_3_6_1
|
The requirements are as detailed in 6.2 of IEC 61508-1, with the following additional requirements. |
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. |
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:
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. |
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. |
Any software lifecycle model may be used provided all the objectives and requirements of this clause are met. |
Each phase of the software safety lifecycle shall be divided into elementary activities with the scope, inputs and outputs specified for each phase. |
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. |
Any customisation of the software safety lifecycle shall be justified on the basis of functional safety. |
Quality and safety assurance procedures shall be integrated into safety lifecycle activities. |
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. |
The results of the activities in the software safety lifecycle shall be documented (see Clause 5). |
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. |
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. |
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. |
Requirement: EN-61508-3 clause 7.2.2.3: sufficent requirement specification for FSA EN_61508_3_7_2_2_3
|
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. |
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. |
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. |
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. |
The software safety requirements specification shall specify and document any safety-related or relevant constraints between the hardware and the software. |
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. |
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. |
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:
b) the requirements for the software systematic capability:
|
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.). |
Requirement: EN-61508-3 clause 7.2.2.12: consideration of peformance characteristics EN_61508_3_7_2_2_12
|
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. |
Operational parameters shall be protected against: a) invalid, out of range or untimely values; b) unauthorized changes; c) corruption. |
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. |
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:
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. |
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. |
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. |
Requirement: EN-61508-3 clause 7.3.2.5: criteria for accomplishing software validation EN_61508_3_7_3_2_5
|
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. |
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). |
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:
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. |
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. |
The design method chosen shall possess features that facilitate software modification. Such features include modularity, information hiding and encapsulation. |
The design representations shall be based on a notation which is unambiguously defined or restricted to unambiguously defined features. |
As far as practicable the design shall keep the safety-related part of the software simple. |
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. |
Requirement: EN-61508-3 clause 7.4.2.8: implementation of safety and non-safety functions EN_61508_3_7_4_2_8
|
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. |
Requirement: EN-61508-3 clause 7.4.2.9: implementation of different safety integrity levels EN_61508_3_7_4_2_9
|
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. |
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. |
Requirement: EN-61508-3 clause 7.4.2.11: requirement for 7.4.3 of IEC 61508-2 for safety function implementations EN_61508_3_7_4_2_11
|
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. |
Requirement: EN-61508-3 clause 7.4.2.12: pre-existing software element implementation EN_61508_3_7_4_2_12
|
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:
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. |
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). |
Requirement: EN-61508-3 clause 7.4.2.14: appropiate application of data generation languages EN_61508_3_7_4_2_14
|
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. |
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). |
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. |
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. |
A software on-line support tool shall be considered to be a software element of the safety-related system |
Software off-line support tools shall be selected as a coherent part of the software development activities. |
The selection of the off-line support tools shall be justified. |
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. |
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. |
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. |
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. |
Requirement: EN-61508-3 clause 7.4.4.8: controlling failures of safety related system EN_61508_3_7_4_4_8
|
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. |
The compatibility of the tools of an integrated toolset shall be verified. |
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. |
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. |
Programming languages for the development of all safety-related software shall be used according to a suitable programming language coding standard. |
Requirement: EN-61508-3 clause 7.4.4.13: programming code conventions and standards EN_61508_3_7_4_4_13
|
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 |
Requirement: EN-61508-3 clause 7.4.4.14: development support tools for automatic code generation EN_61508_3_7_4_4_14
|
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. |
Requirement: EN-61508-3 clause 7.4.4.15: configuration management for off-line support tools EN_61508_3_7_4_4_15
|
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. |
Requirement: EN-61508-3 clause 7.4.4.16: qualified versions for configuration management EN_61508_3_7_4_4_16
|
Configuration management shall ensure that for tools in classes T2 and T3, only qualified versions are used. |
Requirement: EN-61508-3 clause 7.4.4.17: compatible tools for configuration management EN_61508_3_7_4_4_17
|
Configuration management shall ensure that only tools compatible with each other and with the safety-related system are used. |
Requirement: EN-61508-3 clause 7.4.4.18: qualification of new off-line support tools versions EN_61508_3_7_4_4_18
|
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. |
Requirement: EN-61508-3 clause 7.4.4.19: documentation of responsibility for 7.4.4 EN_61508_3_7_4_4_19
|
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). |
Requirement: EN-61508-3 clause 7.4.5.1: documentation of responsibility for 7.4.5 EN_61508_3_7_4_5_1
|
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). |
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. |
The software shall be produced to achieve modularity, testability, and the capability for safe modification. |
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. |
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. |
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. |
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). |
Requirement: EN-61508-3 clause 7.4.7.2: verification of not producing unintended functions EN_61508_3_7_4_7_2
|
This verification shall show whether or not each software module performs its intended function and does not perform unintended functions. |
The results of the software module testing shall be documented. |
The procedures for corrective action on not passing the test shall be specified. |
Software integration tests shall be specified during the design and development phase (see 7.4.5). |
Requirement: EN-61508-3 clause 7.4.8.2: integration test specification requirements EN_61508_3_7_4_8_2
|
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. |
Requirement: EN-61508-3 clause 7.4.8.3: software system integration test specification EN_61508_3_7_4_8_3
|
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. |
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. |
Requirement: EN-61508-3 clause 7.4.8.5: impact analysis for modifications durin software integration EN_61508_3_7_4_8_5
|
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. |
Requirement: EN-61508-3 clause 7.5.2.1: integration test specification for compabiltiy EN_61508_3_7_5_2_1
|
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. |
Requirement: EN-61508-3 clause 7.5.2.2: integration test specification requirements EN_61508_3_7_5_2_2
|
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. |
Requirement: EN-61508-3 clause 7.5.2.3: clear distinction between developer and user activites EN_61508_3_7_5_2_3
|
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. |
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. |
Requirement: EN-61508-3 clause 7.5.2.5: integration of software/PE integration test specification EN_61508_3_7_5_2_5
|
The software shall be integrated with the safety-related programmable electronic hardware in accordance with the software/PE integration test specification (hardware and software). |
Requirement: EN-61508-3 clause 7.5.2.6: integration system impact analysis when required EN_61508_3_7_5_2_6
|
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. |
Test cases and their expected results shall be documented for subsequent analysis. |
Requirement: EN-61508-3 clause 7.5.2.8: integration test documentation of test results and critera EN_61508_3_7_5_2_8
|
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. |
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. |
The validation activities shall be carried out as specified the in validation plan for software aspects of system safety. |
Requirement: EN-61508-3 clause 7.7.2.3: document division of responsibility for 7.7 EN_61508_3_7_7_2_3
|
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). |
The results of validating the software aspects of system safety shall be documented. |
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. |
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. |
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:
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. |
Software tools shall meet the requirements of 7.4.4. |
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. |
Prior to carrying out any software modification, software modification procedures shall be made available (see 7.16 of IEC 61508-1). |
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. |
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. |
The impact analysis results obtained in 7.8.2.3 shall be documented. |
Requirement: EN-61508-3 clause 7.8.2.5: software safety lifecycle for modifications EN_61508_3_7_8_2_5
|
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. |
Requirement: EN-61508-3 clause 7.8.2.6: modification of safety-related software requirements EN_61508_3_7_8_2_6
|
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. |
Modification shall be carried out as planned. |
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. |
Requirement: EN-61508-3 clause 7.8.2.9: documentation of details of all modifications EN_61508_3_7_8_2_9
|
Information on the details of all modifications shall be documented. The documentation shall include the re-verification and re-validation of data and results. |
The assessment of the required modification or retrofit activity shall be dependent on the results of the impact analysis and the software systematic capability. |
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. |
Requirement: EN-61508-3 clause 7.9.2.2: software verification planning requirements EN_61508_3_7_9_2_2
|
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. |
The software verification shall be performed as planned. |
Evidence shall be documented to show that the phase being verified has, in all respects, been satisfactorily completed. |
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. |
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:
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:
|
Requirement: EN-61508-3 clause 7.9.2.7: software development lifecycle verification activities EN_61508_3_7_9_2_7
|
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). |
Requirement: EN-61508-3 clause 7.9.2.8: software verification requirements between phases EN_61508_3_7_9_2_8
|
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:
|
Requirement: EN-61508-3 clause 7.9.2.9: requirements after the software architecture design has been completed EN_61508_3_7_9_2_9
|
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:
d) check for incompatibilities between the following:
|
Requirement: EN-61508-3 clause 7.9.2.10: requirements after the software system design has been completed EN_61508_3_7_9_2_10
|
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:
d) check for incompatibilities between:
|
Requirement: EN-61508-3 clause 7.9.2.11: software verification requirements after software module design EN_61508_3_7_9_2_11
|
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:
d) check for incompatibilities between:
|
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. |
Verification of data. a) The data structures shall be verified. b) The application data shall be verified for:
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:
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:
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:
e) All communication interfaces and associated software shall be verified for an adequate level of:
|
Verification of timing performance: predictability of behaviour in the time domain shall be verified. |