IEC KHBO, Hobufonds SAFESYS ing. Alexander Dekeyser ing. Kurt Lintermans

Transcription

1 IEC KHBO, Hobufonds SAFESYS ing. Alexander Dekeyser ing. Kurt Lintermans

2 page 2 PART 1 : GENERAL REQUIREMENTS 1 Scope The first objective of this standard is to facilitate the development of application sector international standards by the technical committees responsible for the application sector The second objective is to enable the development of E/E/PE safety related systems where application sector international standards may not exist This standard applies to all safety-related systems (SRS), irrespective of the application, when one or more of such systems incorporate electrical/electronic/programmable electronic (E/E/PE) devices. This standard is not intended for safety-related systems whose failure couldn t have an impact on the safety of persons and/or the environment, nor for simple systems that have only to satisffy with a very low safety integrity level. In order to deal in a systematic way with the activities necessary for ensuring the functional safety, this standard uses an overall safety lifecycle. This standard uses a general approach. (e.g. : the safety integrity levels (SIL s) aren t specified for sector applications) 2 Conformance to this standard It shall be demonstrated that the requirements in each clause and subclause of this standard have been met. The degree to which a requirement is to be satisfied depends on a number of factors, dependent on the application. For low complexity safety- related systems certain requirements may be unnecessary. 3 Documentation to specify the necessary information to be documented in order that : - all phases of the overall safety lifecycles - the management of functional safety verification and the functional safety assesment can be effectively performed requirements - sufficient information for each phase of the lifecycles - sufficient information required for the management of functional safety - sufficient information required for the implementation of a functional safety assesment - unless justified, the information shall be as stated in the various clauses of this standard - documentation shall be clear - documentation shall have titles or names - documentation structure may take account of company procedures - the documents shall be so structured to make it easy to search for relevant information - the documents shal be revised,amended,reviewed,approved and be under the control of a scheme 4 Management of functional safety to specify : - the management of technical activities during the lifecycle phases - the responsibilities of the persons,departments and organizations requirements - specify all management and technical activities necessary to ensure that the E/E/PE systems achieve the required functional safety examples : assesment activities,procedures for ensuring the competence of the persons involved.. page 2

3 page 3 - the activities shall be implemented and progress monitored - those specified as responsible for the management of functional sasfety activities shall be informed of the assigned responsibilities to them - suppliers shall deliver products or services as specified 5 Overall safety lifecycle requirements 5.1 General In order to deal in a systematic manner an overall safety lifecycle has been developed which encompasses E/E/PE SRSs,other technology SRSs and external risk reduction facilities The overall safety lifecycle is shown on figure 2, page 33. For all phases of the overall safety lifecycle the following has been specified : - objectives - requirements 5.2 Concept This is the first phase of figure2 To develop a level of understanding of the equipment under control (EUC) and its environment - knowledge of the EUC, its required control functions and the physical environment - to determine the likely sources of hazards - to obtain information about the determined hazards - to obtain information about the current safety regulations - hazards due to interaction with other EUC s 5.3 Overall scope definition s - to determine the boundary of the EUC and its control system - to specify the scope of the hazard and risk analysis - the physical equipment shall be specified - the external events to be taken into account in the hazard and risk analysis shall be specified - the subsystems which are associated with the hazards shall be specified - the type of accident-initiating events shall be specified 5.4 Hazard and risk analysis s - to determine the hazards and hazardous events for all reasonably foreseeable circumstances - to determine the event sequences leading to the hazardous events - to determine the EUC-risks associated with the hazardous events - a hazard and risk analysis shall be undertaken page 3

4 page 4 - consideration shall be given to the elimination of the hazards, although this is not the scope of this standard - the hazards and hazardous events shall be determined under all reasonably foreseeable circumstances - the event sequences leading to the hazardous events shall be determined - the likelihood of the hazardous events shall be specified - the potential consequences shall be specified - either quantitative or qualitative techniques can be applied - the information and results which constitute the hazard and risk analysis shall be documented and maintained 5.5 Overall safety requirements to develop the specification for the overall safety requirements, in terms of : - the safety functions requirements and - the safety integrity requirements - the safety functions necessary to ensure the required functional safety for each determined hazard shall be specified. - the necessary risk reduction shall be determined (in either a qualitative or quantitative method) - Where failures of the EUC control system place a demand on one or more E/E/PE SRS s, and where the intention is not to designate the EUC control system as a safety-related system, special requirements shall apply. - If those special requirements cannot be met, then the EUC control system shall be designated as a safety-related system. - The safety integrity requirements, in terms of the necessary risk reduction, shall be specified for each safety function 5.6 Safety requirements allocation s - to allocate the safety functions to the designated E/E/PE safety-related systems - to allocate a SIL (safety integrity level) to each safety function - the designated SRS s that are to be used to achieve he required functional safety shall be specified - the skills and resources available during all phases of the overall safety lifecycle shall be considered - the allocation shall be done in such a way that all safety functions are allocated and the safety integrity requirements are met for each safety function - appropriate techniques shall be used for the allocation - the allocation shall proceed taking into account the possibility of common cause failures (this standard is specifically concerned with the allocation of the safety requirements to E/E/PE SRS s) - Several safety related systems can be treated as independent, but therefore they shall meet a number of requirements. - If not all those requirements can be met, they shall not be treated as independent, unless an anlysis has been carried out which shows that they are sufficiently independent. - the safety integrity requirements for each safety function allocated shall be specified in terms of the safety integrity level (SIL). There is a difference between E/E/PE SRS s operating in a LOW and HIGH demand mode of operation. - When there are different SIL s in one safety system, all the safety functions shall be treated as belonging to the safety function with the highest SIL, unless sufficient independence can be shown. page 4

5 page 5 - An architecture that is comprised of only a single E/E/PE SRS oof SIL 4 shall be permitted only if a number of criteria have been met. - any information, obtained from the allocation, shall be documented 5.7 Overall operation and maintenance planning to develop a plan for operating and maintaining the E/E/PE SRS s, to ensure that the required functional safety is maintained during operation and maintenance - a plan shall be prepared which shall specify the following : a) routine actions necessary to maintain the required functional safety b) actions and constraints during special events (start-up, ), to prevent an unsafe state c) documentation which needs to be maintained about audits and hazardous events d) scope of the maintenance activities e) actions necessary in the event of hazards occuring f) contents of the chronological documentation of operation and maintenance activities - the routine maintenance activities should be determined by systematic analysis - the plan shall be agreed upon with those responsible for the future operation and maintenance 5.8 Overall safety validation planning to develop a plan to facilitate the overall safety validation of the E/E/PE SRS s - the plan shall include the following : a) when shall the validation take place? b) who shall carry out the safety validation? c) relevant modes of the EUC d) specification of the E/E/PE SRS s which need to be validated e) technical strategy for the validation f) measures and techniques that shall be used g) required validation environment h) pass and fail criteria i) policies and procedures for evaluating the results 5.9 Overall installation and commissioning planning s to develop a plan for the - installation - commissioning of the E/E/PE SRS s in a controlled manner, to ensure that the required functional safety is achieved - the plan for the installation shall specify : a) installation schedule b) procedures for the installation c) those responsible d) the sequence in which the various elements are integrated e) criteria for declaring the parts ready for installation and for declaring installation activities complete f) procedures for the resolution of failures and incompatibilities - the plan for te commissioning shall specify : a) commissioning schedule b) procedures for the commissioning page 5

6 page 6 c) those responsible d) the relationships to the different steps in the installation e) relationships to the validation 5.10 Realisation : E/E/PE to create E/E/PE SRS s conforming to the specification for the E/E/PES safety requirements en Overall installation and commissioning s - to install the E/E/PE SRS s - to commission the E/E/PE SRS s - installation in accordance with the plan - information during installation shall be documented - commissioning in accordance with the plan - information during commissioning shall be documented 5.12 Overall safety validation to validate that the E/E/PE SRS s meet the specification for the overall safety requirements, in terms of the overall safety functions requirements and overall safety integrity requirements - in accordance with the overall safety validation plan - equipment shall be calibrated - information shall be documented during validation : a) chronological form b) version of the specification used c) the safety functions being validated d) tools and equipment used e) results of the validation activities f) item under test, procedures applied, test environment g) discrepancies between expected and actual results - When discrepancies occur, the analysis made and the decisions taken shall be documented 5.13 Overall operation, maintenance and repair to operate, maintain and repair the E/E/PE SRS s in order that the required functional safety is maintained - the following shall be implemented : plan for operation, maintentance and repair procedures for E/E/PE SRS s and software - initiation of the following actions : page 6

7 page 7 implementation of procedures, following of maintenance schedules, maintaining of documentation, functional safety audits, documenting of modifications - chronological documentation 5.14 Overall modification and retrofit to ensure that functional safety is appropriate during and after the modification and retrofit activities - procedures shall be planned - an authorized request is necessary, and shall detail the following : hazards which may be affected, proposed change, reasons for the change - an impact analysis shall be carried out - the results shall be documented - authorization to carry out the modification or retrofit activities depend on the results of the impact analysis - all modifications which have an impact on the functional safety shall return to an appropriate phase of the lifecycle - chronological documentation 5.15 Decommissioning or disposal to ensure that the functional safety is appropriate during and after the decommissioning or disposal activities - impact analysis - results shall be documented - authorized request necessary - authorization shall be dependent on the results of the impact analysis - a plan shall be prepared which shall include procedures for closing down and dismantling the E/E/PE SRS s - return to an appropriate phase in the safety lifecycle if any decommissioning or disposal activities has an impact on the functional safety - chronological documentation 5.16 Verification to demonstrate for each phase of the lifecycle that the outputs meet the requirements specified for the phase - a plan for verification for each phase - the plan shall refer to the criteria, techniques, tools to be used in the verification activities - the verification shall be carried out according to the verification plan - documentation shall be collected as evidence that the phase has been satisfactorily completed 6 Functional safety assessment page 7

8 page to investigate and arrive at a judgement on the functional safety achieved by the E/E/PE SRS s one or more persons shall be appointed to carry out the assessment - those persons shall have access to all persons involved in any phase of the lifecycle - the assessment shall be applied to all phases - the tools should be subject to the assessment - the following shall be considered : a) the work done since the previous functional safety assessment b) plans or strategy for implementing further functional assessments of the lifecycle c) recommendations of the previous assessments - the assessment activities shall be consistent and planned - the plan for the functional safety assessment shall specify : a) those to undertake the assessment b) the outputs from each assessment c) the scope of the assessment d) the safety bodies involved e) the resources required f) the level of independance of the assessors g) the competence of the assessors - the plan has to be approved by the assessors - the assessors shall be competent - the assessors have to have a minimum level of independence (see specific tables) Annex A : example document structure This annex provides an example documentation structure and method for specifying the documents for structuring the information in order to meet the requirements. The documentation has to contain sufficient information necessary to effectively perform : - each phase of the safety lifecycles - the management of functional safety - functional safety assessments The amount of information necessary depends on the complexity and size of the safety related system In this annex, the document is specified in two parts : - document kind - activity or object The example document structure in this annex provides a way in which the information COULD be structured. Annex B : competence of persons This annex outlines considerations for ensuring that persons who have responsibilities for any lifecycle activity are competent to discharge those responsibilities. page 8

9 page 9 PART 2 : REQUIREMENTS FOR E/E/PE SAFETY RELATED SYSTEMS 1 Scope This part of this standard : - applies to any SRS, which contains at least 1 electrical, electronic or programmable electronic based component - applies to all subsystems and their components within an E/E/PE SRS specifications how to refine the information concerning the overall safety requirements and their allocation to E/E/PE SRSs, and specifications how the overall safety requirements are refined into E/E/PES safety functions requirements and E/E/PES safety integrity requirements - specifications requirements for activities that are to be applied during the design and manufacture of the E/E/PE SRSs, these applications include the measures and techniques, which are graded against the SIL, for the avoidance of and control of faults and failures - specifications the information necessary for carrying out the installation, commisioning and final safety validation of the E/E/PE SRS - provides requirements for the preparation of information and procedures needed by the user for the operation and maintenance of the E/E/PE SRSs - specifications requirements to be met by the organization carrying out any modification of the E/E/PE safety related systems - NOTE : This part of this standard is mainly directed at suppliers and/or in-company engineering departments. 2 E/E/PES safety lifecycle requirements 2.1 General s and requirements : general For all phases of the E/E/PE system safety lifecycle the folowing has been specified - the objectives - the requirements s - to structure, in a systematic manner, the phases in the E/E/PE system safety lifecycle in order to achieve the required functional safety - to document all information relevant to the functional safety - the E/E/PE system safety lifecycle is shown on figure2, page 12 - each phase of the lifecycle is divided into elementary activities, - it has a scope, inputs and outputs - the outputs of each phase shall meet the objectives and requirements and must be documented page 9

10 page E/E/PE system safety requirements specification to specify the requirements for each E/E/PE safety related system,in terms of the required safety functions and the required safety integrity, in order to achieve the required functional safety General requirements the specification of the E/E/PE system safety requirements shall : a) be derived from the allocation of safety requirements and from those requirements specified during functional safety planning b) must be expressed and structured so that they are unambiguous, precise and written to be understandable by those that will utilize them at any stage of the E/E/PE system safety lifecycle c) contain the requirements for the E/E/PE system safety functions and the requirements for E/E/PE system safety integrity E/E/PE SYSTEM safety requirements A ) the E/E/PE system safety functions requirements specification shall contain : a) a description of all the safety functions necessary to achieve the required functional safety, which shall, for each function : - provide detailed requirements sufficient for the design and development of the E/E/PE safety related systems - include the manner in which the E/E/PE safety related systems are intended to achieve or maintain a safe state for the EUC - specify whether or not continuous control is required, and for what periods, in achieving a safe state of the EUC - specify if applicable for low or high demand mode of operation b) throughput and response time performance c) E/E/PE safety related systems and operator interfaces necessary to achieve the required functional safety d) relevant information to functional safety that can influence the system e) all interfaces between the E/E/PE safety related systems and other systems f) all relevant modes of operation of the EUC (preparation for use, steady state of operation, shut down, maintenance,...) g) all required modes of behaviour of the E/E/PE safety related systems in particular failure behaviour and the required response (alarms, auto shut-down,...) of the E/E/PE safety related systems shall be detailed h) the significance of all hardware/software interactions i) worst-case analysis for the E/E/PE safety related subsystems j) requirements for procedures for starting up and restarting the E/E/PE safety related systems k) the extremes of all environmental conditions during the lifecycle (manufacture, installing, commisioning, maintenance,..) l) the electromagnetic environment which is likely to be encountered during operation B) the E/E/PE system safety integrity requirements specification shall contain : a) the SIL for each safety function b) whether the target failure measure for the specified SIL is applicable to E/E/PE safety related systems operating in low or high demand mode of operation c) the requirements, constraints, functions and facilities to enable the proof testing of the E/E/PE hardware to be undertaken d) the electromagnetic immunity limits which are required to achieve electromagnetic compatibility page 10

11 page E/E/PE system safety validation planning To plan the validation of the safety of the E/E/PE safety related systems Planning shall be carried out to specify the steps (procedural and technical) that are to be used to demonstrate that the E/E/PE safety related systems satisfy the safety requirements specification planning for validation shall consider : - the relevant modes of operation (preparation for use, steady state of operation, shut down, maintenance,...) - reference to the E/E/PE system safety requirements specification - the procedures to be applied to validate that each safety function is correctly implemented and has the required safety integrity and the pass/fail criteria for accomplishing the tests - the required environment in which the testing is to take place - the test evaluation procedures - the test procedures and performance criteria to be applied to validate the specified electromagnetic immunity levels - failure resolution policies and procedures 2.4 E/E/PE system design and development To design and implement the hardware of the E/E/PE safety related systems to meet the safety functions and safety requirements specified for those E/E/PE safety related systems General requirements - The design shall be created in accordance with the E/E/PE system safety requirements specification - If safety functions and non- safety functions or if safety functions of different SILs are to be implemented in the same design, then the method of achieving the independence and the justification of the method shall be documented - If a E/E/PE safety related systems is to implement both safety and non-safety functions, then all the hardware and software shall be treated as safety related unless it can be shown that the implementation of the safety and non-safety functions is sufficiently independant (failure of non-safety functions does not affect the safety functions), the safety-related functions should be separated from the non-safety-related functions, if possible - For an E/E/PE safety related systems that implements safety functions of different SILs, the hardware and software shall be treated as belonging to the highest SIL unless it can be shown that the safety functions of the different safety integrity levels is sufficiently independant - The requirements for safety-related software shall be made available to the E/E/PES developer who shall review the requirements to ensure they are adequately specified, in particular the safety functions, the E/E/PE system safety integrity requirements, the equipment and operator interfaces - The E/E/PE system design documentation shall specify those techniques and measures necessary during the E/E/PE system safety lifecycle phases to achieve the SIL and shall justify the techniques and measures chosen to form an integrated set that satisfies the required SIL for the control of random hardware faults The design shall include the overall hardware and software architecture that satisfies the hardware and systematic safety integrity requirements as appropriate and shall include the diagnostic coverage and proof test interval that satisfies the hardware safety integrity requirements. for estimating the probability of hardware failure The following procedure shall be adopted in estimating the probalility of hardware failure for E/E/PE safety related systems to determine whether they meet the required SIL for a single safety function page 11

12 page 12 a) model the architecture, the architecture that has been developed during design shall be presented in the following way, allowing it to be analysed - each safety function must be selected separately - the components and subsystems ( eg sensors, logic system components, final elements) must be numbered and listed - the connection and interaction of the components and subsystems of the E/E/PE safety related systems must be studied in order to model that part of the overall hardware architecture that implements the safety function under consideration,this involves deciding which failure modes of the components and subsystems are in a series configuration and which are in parallel - b) the E/E/PE safety related systems parameters will be established as follows : - the environmental stress parameters must be considered for the components and subsystems, the average probability of failure can then be determined using failure rate data and/or failure modes and effects analysis data - if subsystem reliability data is unavailable, a failure mode and effects analysis must be carried out,then there can be decided upon which failures the relevant safety function will fail, the failure probabilities of those failure modes are then summed to provide the overall probability of failure for that subsystem - the susceptibility of the E/E/PE safety related systems must be determined to common cause failures and a method to account for these must be found - the proof test intervals must be established for failures which aren t automatically revealed - the repair times for revealed failures need to be established - the diagnostic coverage and diagnostic test interval must be established c) the target SIL must be met by carrying out the following - a reliability model of the E/E/PE safety related systems for each safety function assesed must be created - carry out a reliability prediction of the relevant safety function and compare the result to the target failure measure of the safety integrity requirement for the relevant safety function - if it is not achieved then the critical components, subsystems and/or parameters must be determined; an evaluation must be made of the effect of possible improvement measures on the critical components, subsystems or parameters; the applicable improvements need to be selected and implemented and these necessary steps need to be repeated until the new probability of a hardware failure is established d) the diagnostic coverage shall be determined according to the following principles : - diagnostic coverage may be achieved by comparison checks such as monitoring, additional routines such as checksums on memory, using designs which fail to a safe state for specificationific failure modes, test by external stimuli - the analysis used to determine the diagnostic coverage shall include all of the components or subsystems (electrical, electronic, electromechanical ) which are required in order to achieve that safety function, all of the possible dangerous modes of failure that will lead to an unsafe state shall be considered for the components and subsystems - on the detection of a fault, that part of the E/E/PE safety related systems operating the diagnostic tests shall automatically put the EUC in a safe state, isolate the faulty subsystem and indicate that a fault has been detected e) diagnostic coverage shall be determined as follows : - a failure mode and effect analysis will be carried out to determine the effect of each failure mode in the absence of diagnostic tests - each failure mode whether it leads to a safe or dangerous failure will be categorized - the fractions of the failure probability for each component or group of components corresponding to safe failures and dangerous failures will be calculated - those failure modes that are detected by the diagnostic tests will be determined - the probability of dangerous failures,detected by the diagnostic tests must be calculated - then this result must be divided by the total prob of dangerous failure for the corresponding hardware subsystem or, in total for all of the subsystems associated with a particular safety function, the result is the diagnostic coverage for that subsystem or safety function f) the following information shall be avilable to carry out the above analysis : - a detailed description of the diagnostic tests used page 12

13 page 13 - a detailed block diagram of the E/E/PE safety related systems describing each of their subsystems together with the interconnections for that part of the E/E/PE safety related systems that will affect the safety function under consideration - the hardware schematics of each hardware subsystem (components, interconnections) - the probability of failure for each component or group of components - the failure modes of each component or group of components and the associated percentages of the total failure probability Architectural constraints on hardware safety inegrity The highest hardware safety integrity that can be claimed for a safety function (and hence for a E/E/PE safety related systems ) is limited by the hardware fault tolerance of the subsystems that carry out that safety function On p25 tables 2 & 3 specify architectural constraints on type A & B safety related subsystems ie the hardware fault tolerance requirements related to the diagnostic coverage, for subsystems used as part of E/E/PE safety related systems to implement safety functions with designated SIL A type A subsystem has well defined failure modes of all constituent components, the behaviour of the subsystem can be completely determined under fault conditions and failure data exists from field experience for the subsystem to show that the required target failure measure is met A type B subsystem has NO well defined failure modes of all constituent components OR the behaviour of the subsystem can NOT be completely determined under fault conditions OR NO failure data exists from field experience for the subsystem to show that the required target failure measure is met The hardware fault tolerance is the maximum number of faults in a subsystem, resulting from random hardware failures, that can occur without leading to a dangerous failure of the E/E/PE safety related systems and where one fault directly leads to the occurence of one or more subsequent faults, these are considered as a single fault - in E/E/PE safety related systems where a safety function is implemented through a single channel, the maximum hardware SIL that can be claimed for the complete E/E/PE safety related systems shall be determined by the subsystem that has met the lowest hardware SIL requirements - in E/E/PE safety related systems where a safety fu is implemented through multiple channels of subsystems, the maximum hardware SIL that can be claimed for the complete E/E/PE safety related systems shall be determined by assesing each subsystem against the requirements of tables 2 &3, grouping the subsystems into combinations and analysing those combinations to det the overall hardware SIL for proof tests and diagnostic tests The design must include facilities to execute proof and diagnostic tests for the avoidance of failures A group of techniques and measures will be used to prevent faults during the design and development phase of the E/E/PE system hardware In accordance with the SIL the design method possesses features that facilitate features like verification, validation, modularity or transparency of the complexity control; functionality, subsystem interfaces, sequencing and time-related information, concurrency and synchronisation, documentation and communication must be clearly and precisely expressed Maintenance requirements are formalised at the design stage If possible, automatic testing tools and integrated development tools are used E/E/PE system integration tests are planned during design, the documentation includes the types of tests to be performed, the test environment and pass/fail criteria Activities that can be carried out on the developer s premises are distinguished from those that required access to the user s site for the control of systematic faults For controlling systematic faults, the E/E/PE system design shall possess design features that makes it tolerant against residual design faults in the hardware and software, environmental stresses, mistakes by the operator of the EUC page 13

14 page 14 Maintainability, testability, human capabilities and limitations must be considered for E/E/PE system implementation The design must be based on a decomposition into subsystems and components having its own design and set of integration tests For all subsystems and components, it must be stated whether they are safety-related and if so if they are new and if they have been assessed already Suitability if a previously developed subsystem or component is to be used for safety functions is based on evidence of satisfactory operation 2.5 E/E/PE system integration Integrate and test the E/E/PE safety related systems The E/E/PE safety related systems shall be integrated and tested as specified in the design phase The documentation must be provided concerning integration tests If any modifications are made during integration and testing, the E/E/PE safety related systems is subjected to an impact analysis which identifies affected components and the necessary reverification activities The E/E/PE system integration testing documents the version of the test, the criteria for acceptance, tools and equipment used, results, differences between actual and expected results and if there are any, the analysis made and decisions taken 2.6 E/E/PE system operation and maintenance procedures To develop procedures to ensure that the required safety of the E/E/PE safety related systems is maintained during operation and maintenance Operation and maintenance procedures are prepared to specify : - routine actions to be carried out - actions and constraints necessary to prevent an unsafe state and/or reduce the consequences of a hazardous event - the documentation about system failures and results of audits and tests - maintenance procedures when faults or failures occur including procedures for fault diagnosis and repair, revalidation and maintenance reporting requirements - procedures for reporting maintenance performance - the tools necessary for maintenance and revalidation and procedures for maintaining the tools and equipment the E/E/PE safety related systems operation and maintenance procedures must be upgraded continuously from the results of functional safety audits and tests a systematic method is used for the routine maintenance actions which will reveal failures of safetyrelated components, these methods include fault tree analysis, failure mode and effect analysis and reliability centred maintenance page 14

15 page E/E/PE system safety validation The requirements for safety in terms of the safety functions and the safety integrity must be met - The validation is carried out according to a prepared plan - Test equipment used for validation is calibrated against a standard - Each safety function and all the E/E/PE system operation and maintenance procedures are validated by test and/or analysis - The documentation for each safety function shall state the version of the plan,safety function under test, tools and equipment used,results and differences between expected and actual results The results of the E/E/PE system safety validation testing shall be given to the developer of the EUC 2.8 E/E/PE system modification The required si is maintained after corrections, enhancements or adaptations Documentation shall be established and maintained for each modification activity, including specification of the modification, an analysis of the impact of the modification, all approvals and progress of changes, test cases for components, E/E/PE system configuration managemant history, deviation from normal operations and conditions, necessary changes to system procedures and necessary changes to documentation Manufacturers maintain a system to allow users to check whether it has been subject to a safety recall Modification must be performed with the same level of expertise as the initial development of the E/E/PE safety related systems 2.9 E/E/PE system verification To test and evaluate the outputs of a given phase to ensure correctness and consistency with respecificationt to the products and standards provided as input to that phase The verification of the E/E/PE safety related systems shall be planned concurrently with the development and must be documented The verification planning shall refer to all techniques, criteria and tools to be used for that phase and specifications performed activities to ensure correctness and consistency with respecificationt to the products and standards provided as input to that phase The planning considers the selection of used technniques, test equipment, documentation and the evaluation of verification results The result of each verification activity is documented, stating that the E/E/PE safety related systems passed the verification or the reasons for failures, here is considered items which do not conform to one or more: requirements of the safety lifecycle phase, relevant design standards and relevant safety management requirements Verification shall determine whether the E/E/PE system safety requirements are adequate to satisfy the requirements set out in the E/E/PE system safety requirements allocation and determine whether the E/E/PE system tests adequately consider all the safety requirements and check for incompabilities between the E/E/PE system safety requirements, the safety requirements allocation and the E/E/PE system tests Test cases and their results shall be documented page 15

16 page 16 ANNEX A : CONTROL OF FAILURES - This annex recommends for each SIL techniques and measures for controlling random hardware, systematic, environmental and operational failures - the diagnostic coverage is also determined ANNEX B : AVOIDANCE OF FAILURES - this annex recommends for each SIL techniques and measures to avoid failures in E/E/PE SRS s - the measures to control failures are built-in features of the E/E/PE SRS s, while the measures to avoid failures are performed during the safety lifecycle page 16

17 page 17 PART 3 : SOFTWARE REQUIREMENTS 1 Scope This part : - applies to any software forming part of a safety-related system or used to develop a safety-related system. Such software is termed safety-related software. - requires that safety functions and SIL s have been specified. - establishes requirements for safety lifecycle phases and activities that shall be applied during design an development. - provides requirements for information relating to the software safety validation to be passed to the organisation carrying out the E/E/PES integration - provides requirements for the preparation of information and procedures concerning software needed by the user for the operation and maintenance of the E/E/PE SRS. - provides requirements to be met by the organisation carrying out modifications to safety-related software - provides requirements for support tools 2 Software quality management system 2.1 s see see , with the following additional requirements : - the functional safety planning shall define the strategy for the software procurement, development, integration, verification, validation, modification to the extent required by the SIL - software configuration management should a) manage software changes to maintain the software safety b) guarantee that all actions have been carried out to demonstrate that the required software safety integrity has been achieved c) maintain all configuration items : safety analysis and requirements, software specification and design documents, software source code modules, test plans and results, pre-existing software components and packages. d) apply change-control to avoid unwanted changes e) document the following information : configuration status, release status, justification for approval of all modifications, details of the modification f) formally document the release of safety-related software 3 Software safety lifecycle requirements 3.1 General to structure the development of the software into defined phases and activities page 17

18 page 18 - a safety lifecycle for the development of software shall be selected and specified - quality and safety assurance procedures shall be integrated - each phase shall be divided into elementary activities - it is acceptable to order the software project differently, provided that all the objectives and requirements of each clause have been met - for each lifecycle phase, appropriate techniques and measures shall be used - the results of the lifecycle activities shall be documented - if at any phase a change is required pertaining to an earlier lifecycle phase, then that earlier phase shall be repeated 3.2 Software safety requirements specification s - to specify the requirements for software safety in tems of the requirements for software safety functions and software safety integrity - to specify the requirements for the software safety functions necessary to implement the required safety functions - to specify the requirements to achieve the specified SIL - if the requirements for software safety have already been specified in , they do not need to be repeated - the software requirements shall be derived from the E/E/PE SRS requirements and shall be made available to the software developer - the specification of the requirements for software safety shall be sufficiently detailed - The software developer shall review the information to ensure that the requirements are adequately specified. He shall consder the following : safety functions, architecturof the system, hardware safety integrity requirements, software integrity requirements, capacity and response time performance, equipment and operator interfaces - procedures for resolving disagreements over the assignment of the SIL - the specified requirements for software safety shall be clearly structured - relevant modes for the EUC - document any safety-related or relevant constraints between hardware and software - the software safety requirements shall consider software self-monitoring, monitoring of the PE hardware, sensors and actuators, periodic testing of safety functions while the system is running, enabling safety functions to be testable when the EUC is operational - the non-safety-functions shall be clearly identified 3.3 Software safety validation planning to develop a plan for validating the software safety - to specify the steps that will be used to demonstrate that the software satisfies its safety requirements - the validation plan shall consider : a) when shall the validation take place b) who shall carry out the validation c) relevant modes of the EUC d) what safety-related software needs to be validated for each mode of EUC operation? e) technical strategy for the validation f) the techniques and procedures that shall be used g) the test environment h) pass/fail criteria i) policies and procedures for evaluating the results of the validation, particularly failures page 18

19 page 19 - the technical strategy shall include the following information about the used techniques : a) manual or automated or both b) static or dynamic or both c) analytical or statistical or both - planning with the assessor or with a party representing the assessor - the pass/fail criteria 3.4 Software design and development s - to create a software architecture that fulfils the specified requirements for software safety with respect to the required SIL - to review the requirements placed on the software by the hardware - to choose appropriate tools for the required SIL - to design and implement software that fulfils the specified requirements for software safety - to verify that the requirements for software safety have been achieved General requirements - The responsibility can rest with the supplier alone, the user aone or with both. The division shall be determined during safety validation planning. - the design method chosen shall possess features that facilitate : a) modularity b) comprehension c) verification and validation - testability and the capacity for safe modification - easy software modification possible - unambiguous notation of the design - minimise the safety-related part of the software - where software is to implement both safety and non-safety functions, all of the software shall be treated as safety-related, unless independence can be shown - software functions to execute proof tests and all diagnostic tests to fulfil the safety integrity requirements of the E/E/PE SRS - If standard or previously developed software is to be used, it shall be identified and its suitability shall be justified for software architecture - responsibility (see upper) - a description of the software architecture design shall : a) select and justify a set of techniques and measures necessary to satisfy the specification of requirements b) be based on a partitioning into components/subsystems c) determine all software/hardware interactions d) use an unambiguous notation to represent the architecture e) select the design features to be used for maintaining the safety integrity of all data f) specify appropriate software architecture integration tests - any changes required to the specified safety requirements shall be agreed with the E/E/PE developer and documented for support tools and programming languages - responsibilities (see upper) - a suitable set of tools (languages, compilers, ) shall be selected for the required SIL - The programming language selected shall : a) have a translator/compiler which has either a certificate of validation to a recognised or international standard, or it shall be assessed b) be unambiguoesly defined c) match the characteristics of the application d) contain features that facilitate the detection of programming mistakes e) support features that match the design method - If the upper requirements cannot be satisfied, then a justification is necessary page 19

20 page 20 - coding standards shall be reviewed as fit for purpose by the assessor and used for the development of all safety-related software - the following information should be contained in the source code documentation as a minimum : legal entity, description, inputs and outputs, configuration management history for detailed design and development - responsibilities (see upper) - detailed design requires : requirements for software safety, description of the software architecture design, validation plan - achievement of modularity, testability and the capacity for safe modification - partitioning into software modules - appropriate software system integration tests for code implementation - the source code shall : a) be readable, testable, understandable b) satisfy the requirements for software design c) satisfy the requirements of the coding standards d) satisfy all relevant requirements specified during safety planning - each module of software code should be reviewed for software module testing - testing as specified during software design - the tests shall show that each software module performs its intended function and does not perform unintended functions - the results shall be documented - the procedure for corrective action on failure of test shall be specified for software integration testing - software integration tests shall be specified concurrently during the design and development phase - the tests shall specify the following : a) division into manageable integration sets b) test cases and test data c) types of tests d) test environment e) test criteria f) procedures for corrective action on failure of test - the software shall be tested in accordance with the specified software integration tests. The tests shall show that all software modules perform their intended function and do not perform unintended functions - the results shall be documented - any modification or change during integration shall be subject to an impact analysis 3.5 Programmable electronics integration (hard- and software) s - to integrate the software onto the target PE hardware - to combine the software and hardware in the safety-related PE to ensure their compatibility and to meet the requirements of the intended SIL - integration tests shall be specified during the design and development to ensure the compatibility of the hardware and software in the safety-related PE - the integration tests for PE shall specify the following : a) split of the system into integration levels b) test cases and test data c) types of tests d) test environment page 20

21 page 21 e) test criteria - the integration tests shall distinguish between those activities which can be carried out by the developer on his premises and those that require acces to the user s site - the tests shall distinguish between : a) merging of software system on to the target PE hardware b) E/E/PE integration c) total integration of the EUC and E/E/PE SRS - the software shall be integrated in accordance with the specified integration tests - any modification or change during integration testing shall be subject to an impact analysis - the results shall be documented 3.6 Software operation and modification procedures to provide information and procedures concerning software necessary to ensure that the functional safety is maintained during operation and modification see Software safety validation to ensure that the integrated system complies with the specified requirements at the intended SIL - if the compliance with the requirements for software safety has already been established in , the validation need not be repeated - the validation shall be carried out according to validation planning - the results shall be documented - for each safety function the following shall be documented : a) chronological record of the activities b) version of the software safety validation plan c) the safety function being validated d) tools and equipment used e) results f) discrepancies between expected and actual results - When discrepancies occur : document the analysis made and the decisions taken - the validation shall meet the following requirements a) testing shall be the main validation method for software b) the software shall be exercised by stimulation of input signals, anticipated occurences, undesired conditions c) the software developer shall make available the results to the system developer - software tool qualification requirements are as follows : a) international standard, national standard, a well recognized procedure b) any tools used shall be shown to be suitable for purpose - software validation result requirements are as follows : a) all of the specified requirements for sofware safety are correctly performed and the software does not perform unintended functions b) test cases and their results shall be documented c) the results shall state that the software has passed or the reasons for its failure 3.8 Software modification to make corrections, ensuring that the required SIL is sustained page 21