considered during the design activities The design facilitates decomposition and testing. At all SILs but particularly at 3 and above the following techniques are to be applied in relation to testability: Comprehensive use of failure assertions and pre-conditions to limit the program input space and therefore the number of test cases (R2) Where diverse monitoring is used then it covers the minimum safety requirements (R2) Where state-based design is used then the test coverage of possible states is defined (R2) – ‘impossible’ states should be trapped by assertions. 14 Modification of design To ensure the design method chosen shall possess features that facilitate software modification such as modularity, information hiding and encapsulation 7.4.2.4 For all safety integrity levels ensure that there is evidence that: The software design is modular. The design is maintainable by virtue of its control of complexity and its information hiding features
The functions needed to provide the necessary diagnostic coverage have been included in the design At SIL 3 and above If a communication protocol has been specified formally in the requirements specification then the software design will be based on that formal representation and not on any natural language interpretation of the formal design. Note: If the IEC 61508-2 and IEC 61508-3 assessments are conducted by different persons or teams then the assessors are required to agree that this ToE has been met. 17 Self monitoring and diagnostics To ensure that the design shall include, commensurate with the required , self-monitoring of control flow and data flow. On failure detection, appropriate actions shall be taken 7.4.2.7 For all safety integrity levels ensure that there is evidence that the design: Includes elements for the specified and diagnostics functions specified in the software safety requirements specification. Includes software self-monitoring e.g. watchdogs, windowed watchdogs, sequence of event monitoring, data corruption monitoring. Timeliness of monitoring of safety integrity functions and detection of faults, for high and low demand systems
underflows, etc). This model validation shall be documented Any model used in validation must have a scope, profile, and scale that is equal to or greater than the models that are to be used in the safety related system. Any restrictions to the model state space that are introduced to limit the execution time of the model shall be justified. 26 Detailed design and development To ensure the software safety requirements specification, the description of the software architecture design and the software safety validation plan are available prior to the start of the detailed design, and that there is modularity, structure, testability, the capacity of safe modification, software module design and testing is specified and that structured methods are employed 7.4.5.2, 7.4.5.3, 7.4.5.4 For all safety integrity levels ensure that is evidence that the design is: The necessary information (specification of requirements, architecture design and validation plan for software aspects of system safety) was available prior to the start of software design The design of each module is specified Capable of verification which is expressed in the software module test specification Complete with respect to the requirements specification (objective completeness criteria applied – R2)
Structural test covers all conditions (100% MC/DC ) Probabilistic testing has been performed when appropriate to do so 29 Software integration testing To ensure that software integration tests are specified during the design and development phases; that the specified tests state the test cases and test data, types of test to be performed, the test environment, tools, configuration and programs; that the test criteria on which the completion of the test will be judged; that the procedures for corrective action on failure of test; that any modification resulting from software integration testing is subject to an impact analysis that will determine the software modules impacted and the necessary re-verification and re-design activities. 7.4.8.1 – 7.4.8.5 Where software integration testing is applicable, for all safety integrity levels ensure that there is evidence that: A software integration test specification exists. The software integration test specification is held under configuration management. The software integration test plan has been reviewed. The specified integration specify appropriate test cases and test data The software integration test specification specifies the test environment, test tools, software configuration and requisite test programs. The software integration test specification specifies a pass / fail criterion (or criteria) for each test.
The software has passed integration testing and objective measures of coverage can be (R2). For recorded failure requiring software modification an impact analysis has been performed and recorded. 30 Specification of integration tests To ensure that integration are specified during the design and development phase to ensure the compatibility of the hardware and the software in the device with consideration of the split of the system into integration levels; test cases and test data; types of test to be performed; test environment including tools, support software and configuration description; test criteria on which the completion of the test will be judged; distinction between test activities carried out by the developer on his premises and those that access the user’s site; the specified integration tests for programmable electronics shall 7.5.2.1, 7.5.2.2, 7.5.2.3, 7.5.2.4, 7.5.2.7 For all safety integrity levels ensure that is evidence that: is a software integration test specification. The software integration test specification has a revision number. The software integration test specification is held under configuration management. The software integration test specification has been reviewed. The software integration test specification was written during the design and development phase of the project. The software integration test specification contains evidence of a planned approach to testing the
programmable electronics, any modification or change to the integrated system is subject to an impact analysis that shall determine all the software modules impacted and the necessary re-verification activities. A software lifecycle change procedure exists includes the criteria to be applied by an impact analysis An impact analysis has been performed on the software when a need for modification has arisen The impact analysis information is held under configuration management. The impact analysis information is uniquely identifiable and traceable to a bug report / change request. An approval process exists for authorising modifications on completion of the impact analysis. Modification requests are recorded, dated, uniquely identified and reference impact analysis (the use of a bug tracking system is evidence of this e.g. Bugzilla). The impact analysis clearly identifies the area of the software to be changed. The impact analysis clearly identifies associated documentation to be changed. 32 of results To ensure the documenting of the test cases and their expected 7.5.2.7, 7.5.2.8 For all safety integrity levels ensure that is evidence that:
33 Execution of software aspects of system safety validation To ensure the validation activities are carried out as specified during software safety validation planning and that testing is the main validation method for software; animation and modelling may be used to supplement the validation activities. 7.7.2.2 For all safety integrity levels ensure that there is evidence that: There is a (set of) precisely defined validation configuration(s) There are recorded software validation test results. There are operational profile coverage targets defined, justified and met (R2 for 3+) 34 Recording of results of the software safety validation To ensure the software validation activities are documented in order to record that the specified functions for software safety are correctly performed, that the software system does not perform unintended functions, the test cases and their results and if failed the reason for failure 7.7.2.4, 7.7.2.5, 7.7.2.6, 7.7.2.7, 7.7.2.8, 7.7.2.9 For all safety integrity levels ensure that there is evidence that: The software validation test results have a revision number. The software validation test results are dated. The software validation test results identify the individuals who performed the testing. The software validation test results identify any test environment/equipment used. Only validated/approved test that satisfy ToE 18 (para 7.4.4) shall be used
and that details of all modifications shall be documented, including references to: the modification request; the result of the impact analysis; software configuration management history; deviation from normal operations and conditions; all documented information affected by the modification activity; re-verification and revalidation of data results. Identify and their level of competency Specification of the modification Planning of the verification of the modification of revalidation and testing of the modification to the extent required by the SIL Modifications to the software have been identified i.e. the revision control system contains information of the change, what was changed and when it was changed. All modifications are recorded 39 Verification planning To ensure that the verification of software is planned concurrently with the development for each phase of the software safety lifecycle and this information shall be documented, and that the planning refers to the criteria, techniques and tools to be used in the verification activities 7.9.2.1, 7.9.2.2 For all safety integrity levels ensure that there is evidence that: For each phase of development (design and coding) that verification activities have been planned. Evidence of planned reviews for these phases is sufficient. 40 Verification of the software (general) To ensure that verification of the software is performed at each stage 7.9.2.3, 7.9.2.4, 7.9.2.5, For all safety integrity levels ensure that there is evidence that: