CONTRACT RESEARCH REPORT. Developing advisory software to comply with IEC HSE. Prepared by Adelard for the Health and Safety Executive

Transcription

1 HSE Health & Safety Executive Developing advisory software to comply with IEC Prepared by Adelard for the Health and Safety Executive CONTRACT RESEARCH REPORT 419/2002

2 HSE Health & Safety Executive Developing advisory software to comply with IEC P Froome & C Jones Adelard Drysdale Building Northampton Square London EC1V 0HB United Kingdom This report gives constructive technical guidance on how to develop advisory software so as to achieve compliance with IEC Functional safety of electrical/electronic/programmable electronic safetyrelated systems. This guidance defines the scope of a limited class of safety-related advisory software, explains in a software context what IEC is trying to achieve at each key point of the safety lifecycle. Two practical illustrations are given of quality management procedures to collect compliance evidence. The first is a quality management system (QMS) which is 3rd party certified to ISO The second recognises that many software developers will not have a 3rd party certified QMS, and even fewer specifically for software development. This report and the work it describes were funded by the Health and Safety Executive (HSE). Its contents, including any opinions and/or conclusions expressed, are those of the author alone and do not necessarily reflect HSE policy. HSE BOOKS

3 Crown copyright 2002 Applications for reproduction should be made in writing to: Copyright Unit, Her Majesty s Stationery Office, St Clements House, 2-16 Colegate, Norwich NR3 1BQ First published 2002 ISBN All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written permission of the copyright owner. ii

4 FOREWORD This report gives technical guidance to software developers on how to comply with IEC 61508, but solely for the limited class of safety-related advisory software. Explicitly excluded is software that has any degree of online control over machinery or plant. This guidance should be used in conjunction with IEC It is recommended that developers familiarise themselves with The Engineer s Responsibility for Computer Based Decisions, published by The Institution of Chemical Engineers, Geo. E. Davis Building, Railway Terrace, Rugby, CV21 3HQ, UK. The developer s goal is to produce advisory software of demonstrable safety integrity, assessed on the basis of recorded evidence that the requirements of IEC have been met. An explicit quality management approach is recommended to facilitate the systematic gathering of compliance evidence to make possible the assessment of software safety integrity. The developer will need to develop suitable quality management procedures, or adapt existing procedures, to ensure that the evidence, illustrated in Appendices 1 and 2, is collected in a manner suitable for the assessment process. HSE invites comments on the practicality and effectiveness of the recommended approach, and on any other significant aspect of the safety integrity of advisory software. Please send your comments to Edward Fergus Technology Division 357 Magdalen House Stanley Precinct Bootle Merseyside L20 3QZ. iii

5 iv

6 CONTENTS FOREWORD...iii CONTENTS... v EXECUTIVE SUMMARY...vii 1. ADVISORY SOFTWARE SAFETY ASPECTS OF ADVISORY SOFTWARE CHARACTERISTICS OF ADVISORY SOFTWARE IEC FUNDAMENTALS, AND ADVISORY SOFTWARE FUNCTIONAL SAFETY, SAFETY INTEGRITY, AND sil FUNCTIONAL SAFETY OF AN ADVISORY SOFTWARE SYSTEM SIL ASSESSMENT THE SOFTWARE DEVELOPER S ROLE IN SIL ASSESSMENT THE ORGANISATION OF IEC MANAGING AND ASSESSING FUNCTIONAL SAFETY HARDWARE ISSUES FOR ADVISORY SOFTWARE THE IEC SAFETY LIFECYCLE PLANNING AND ASSESSING FUNCTIONAL SAFETY SOFTWARE QUALITY MANAGEMENT DOCUMENTATION COMPLIANCE MATRIX Appendix 1: IEC compliance illustrated using a certified QMS Appendix 2: IEC compliance using a non-certified or non-software QMS Appendix 3: Generic SIL assessment of advisory software v

7 Printed and published by the Health and Safety Executive C30 1/98 vi

8 EXECUTIVE SUMMARY The Health and Safety Executive both develops safety-related software internally and also commissions software from external developers. Safety-related software must achieve an adequate standard of safety integrity. HSE has adopted the international standard IEC Functional safety of electrical/ electronic/ programmable electronic safety-related systems as one acceptable criterion of safety integrity. This report relates to a limited class of software an offline advisory system which assists a human expert in some well defined way to assess risk arising from a hazardous industrial installation or activity. The Health and Safety Executive has developed technical guidance to indicate to developers how to comply, for this limited class of software, with IEC to achieve adequate software safety integrity. Two detailed illustrations are given of how to use quality management procedures to collect compliance evidence. The first uses a quality management system (QMS) which is 3rd party certified to ISO The second recognises that many software developers will not have a 3rd party certified QMS, and even fewer specifically for software development. Dr. Peter Froome and Dr. Claire Jones of Adelard provided these two illustrations and the safety justification documentation scheme, based on Adelard s practical experience of developing and assessing high integrity software. vii

9 Printed and published by the Health and Safety Executive C30 1/98 viii

10 1. ADVISORY SOFTWARE 1.1 SAFETY ASPECTS OF ADVISORY SOFTWARE As part of its regulatory work, the Health and Safety Executive must assess the risk arising from hazardous industrial installations and activities. Several factors determine the quality of the assessment: the personal competence and experience of the assessor; adherence to established engineering practices, standards and published data; peer review by experienced colleagues. Software may be used to assist in the assessment e.g. to mechanise tedious and error-prone calculations, to perform sophisticated mathematical modelling, to search a database, to prioritise a set of non-numerical recommendations. Unfit advisory software can potentially contribute to an unsafe assessment. Potentially unsafe shortcomings include: an incorrect, imprecise or inappropriate calculation; misleading presentation of results; a corrupted or incorrect database; a program bug; an inappropriate regulatory policy assumption or expert judgement built into the code or data. 1.2 CHARACTERISTICS OF ADVISORY SOFTWARE For the purpose of the guidance contained in this report, safety-related software is always used in an advisory way to support the activity of a human assessor. The assessment decision never depends wholly on the software output. The software assists the assessor with time-consuming or error-prone tasks, and it embodies good practice. The characteristics of this advisory software are: off-line use only, no degree of online control over machinery or plant. the response is not time-critical. used in a low-demand mode of operation. the assessor has the skill to recognise gross errors in the software output. the assessor s decision is further peer-reviewed by experts. These defining characteristics of advisory software contribute critically to determining what Safety Integrity level (SIL) the software must achieve. 1

11 2

12 2. IEC FUNDAMENTALS, AND ADVISORY SOFTWARE The following section deals with some of the fundamental concepts used by IEC and how they may be interpreted in the context of an off-line advisory system. 2.1 FUNCTIONAL SAFETY, SAFETY INTEGRITY, AND SIL Definition - safety function: A safety function is the action taken by a safety-related system to reduce the risk associated with a specific hazard, and thus to achieve or maintain a safe state. A software advisory system reduces risk by assisting the assessor with time-consuming or errorprone tasks, and by spreading good practice. Functional safety refers exclusively to the safety functions that the system must perform adequately in order to reduce the risk. The chief safety function for a typical advisory system is that results must be reported with appropriate accuracy and emphasis. A system will usually have other requirements that do not affect safety e.g. choice of methods for design and implementation, choice of calculation algorithm, presentation format of results, time and memory performance constraints. IEC sets performance requirements on the functional safety only. The software developer has a free choice in all non-safety aspects that do not interfere with the correct operation of the safety functions. However, note that it may be impractical to demonstrate this absence of interference. For example, JAVA may be used for convenient GUI programming, but its run-time garbage collection may make predictable execution timing impossible. In that case, the IEC safety requirements must be applied to all affected software and system considerations. Definition - safety integrity, and SIL: Safety integrity is a measure of the overall reliability of the system to perform the safety functions when required. The greater the risk reduction required from a safetyrelated system, the smaller must be the probability that the system will fail to perform the required safety functions. Safety integrity is stated as one of four discrete safety integrity levels or SIL 1-4, where 4 is the most demanding. In determining what safety integrity a system achieves, all causes of failure should be included: random and systematic hardware failure, and systematic software failure. Where failure can be quantified (e.g. random hardware failures), its contribution to the SIL may be stated as a numerical probability of failure on demand. The numerical approach is rarely sufficient for software, and a qualitative approach is needed. In IEC 61508, software is shown to meet its SIL requirement by a mixture of direct and indirect evidence. Direct evidence includes analysis of specification, design or code; functional testing and other validation and verification activities. Indirect evidence shows that sufficient competence and rigour has been used to choose and apply suitable techniques for each lifecycle stage. There is no algorithm for choosing techniques that are guaranteed to achieve safety. A competent technical judgement is needed on factors such as implementation technology, size of system, novelty of design. 3

13 2.2 FUNCTIONAL SAFETY OF AN ADVISORY SOFTWARE SYSTEM The fundamental safety requirement - the safety function - is that the advisory system must not give misleading advice that contributes to an unsafe planning decision. This gives two complimentary requirements, one applying to the software system itself, and the other to the user of the system. the output of the program must be correct according to some suitable specification. For example, a numerical calculation should be defined by a trusted equation, or a competently reviewed decision tree that advises on alternatives, or an answer from a national standard or similar verified source. In practice, this general safety requirement will need expanding into more specific requirements, and these are likely to impose early constraints on the design and implementation of the software. the user must be acceptably competent, i.e. he can reasonably be expected to notice an error in the program output and avoid acting on it. The requirement on the user is beyond the control of the software developer, but it is a key consideration in setting the safety integrity target for the advisory software system. 2.3 SIL ASSESSMENT In IEC terms, a safety-related system reduces the risk that arises from some physical hazard. For example, machinery and plant that generates combustible dust is liable to explode. One way to reduce the risk of injury is to install weak panels in the equipment so that an explosion is directed into a relatively safe area. A computer program may be used to calculate the size and weight of the venting panels. This software is potentially safety-related because it contributes to the decision on safety precautions, given the construction details of the machinery. Taking into account all the factors that mitigate against a dangerous explosion (e.g. a habitually unmanned machinery area, low-combustibility dust), how important is the accuracy (and any other relevant software characteristic) of the panel calculation? To what extent does safety depends on the correct operation of the advisory software? This question how good must the software be? can be restated as what SIL level must be achieved by each safety function that is implemented in software?. SIL assessment involves: identifying the hazard(s) of interest e.g. an exploding dust. deciding how much risk from this hazard is tolerable, and what reduction must be achieved. deciding how the hazard will be addressed, both by the advisory software, and also by other means (e.g. a restriction on the production process that guarantees that a maximum combustibility will not be exceeded). deciding which of SIL 1-4 is appropriate for the advisory software. The principal safety function of the advisory software can be generally stated: the software must not mislead the user into a dangerous decision. Note particularly that the quality of the software is not the only factor in achieving the advisory system s safety function. Other factors include: the expertise of the user, both in the problem domain, and in using the software; the availability of peer review of conclusions; the potential lack of control over program inputs, users etc.; a psychological tendency to trust the results of a computer program. 4

14 A SIL assessment for a particular advisory application (see Appendix 3) that is typical of HSE requirements has shown that the safety integrity requirement is relatively undemanding. The most demanding requirement is for SIL 2 integrity, which permits the advisory system to deliver misleading advice at most once in every 100 occasions and still be satisfactory. 2.4 THE SOFTWARE DEVELOPER S ROLE IN SIL ASSESSMENT The HSE staff commissioning the advisory software development will be primarily responsible for setting the software safety performance requirements. To do this they would normally refer to the Appendix 3 generic SIL assessment to confirm that the assumptions and conclusions are still valid in the proposed new development. If not valid, then the HSE staff would indicate explicitly to the developer any variation. However, a suitably skilled developer may contribute to the SIL assessment and requirements setting, provided that: the result is a clear statement of safety functionality and criticality, and the assessment is well validated by the HSE experts to ensure that it addresses safety concerns adequately. 5

15 6

16 3. THE ORGANISATION OF IEC MANAGING AND ASSESSING FUNCTIONAL SAFETY IEC is primarily a process-based approach rather than a product certification approach. That is, IEC describes a development approach which, if done competently, results in the required functional safety. However, the IEC process also contains some techniques that give a direct measure of software performance e.g. probabilistic testing. In particular, it is feasible to carry out enough tests to give a high confidence that SIL 2 is met for an advisory system, providing there is some diverse way of checking the answer, and the usage profile is reasonably well defined. IEC achieves fitness for safety-related purpose by organising the system development around the fundamental activities of managing and assessing functional safety. functional safety management requires that the system be developed in a systematic manner to ensure that all the issues (e.g. of requirements capture, specification, design, verification, etc.) are addressed adequately, and that evidence is recorded. functional safety assessment examines the evidence collected during system development, and evaluates whether or not confidence is justified that it will perform its required safety functions reliably. A fundamental technique of IEC is the use of a safety lifecycle to impose an order on the system development stages, and to integrate the assessment activities at suitable points as development evidence becomes available. The development of a safety related system proceeds on three levels of detail: an overall safety lifecycle considers the safety-related system from initial concept through specification, design and implementation, to operation and decommissioning. The real-world hazards are identified, and decisions are made as to how these hazards will be dealt with. It is not necessary to use programmable electronics or software (or E/E/PES, electrical/ electronic/ programmable electronic safety-related system ) to solve every safety problem. when it is decided to use an E/E/PES for safety, then a more detailed E/E/PES safety lifecycle is used to select suitable electronic hardware. Again, not every problem needs to be solved with software, and hardware solutions may be appropriate e.g. hard-wired interlock, watchdog timer, redundant or diverse hardware for increased reliability. when it is decided to use software for safety, then a more detailed software safety lifecycle is used to control its development. At specific points within these three lifecycles, the activities to do with managing and assessing the functional safety of the safety related system are carried out. Note that the IEC lifecycle is not intended as a specific mandatory project lifecycle, but more as a generic set of stages onto which a convenient project lifecycle may be mapped. The lifecycle mapping defines when the safety related activities should take place. Note also that IEC describes the safety lifecycle, and not a development lifecycle. For example, a software developer could adopt a waterfall V model, or an iterative spiral model, or some other variation. The safety lifecycle requires only that whatever development model is adopted, all the relevant safety issues are addressed at some point during the development. 7

17 Significant portions of the three safety lifecycles have no significance for advisory software and can therefore be omitted. This customisation is permitted by IEC , clause c. The lifecycle activities that are relevant to advisory software are interpreted below. 3.2 HARDWARE ISSUES FOR ADVISORY SOFTWARE IEC addresses all aspects of a programmable safety related system, both hardware and software. IEC goes into considerable detail on hardware architectures to achieve safety performance e.g. redundant structures and voting, fault tolerance, reliability parameters, diagnostic coverage, etc.. In many cases where high safety performance is needed, the controlling computer will have to be of a special construction to justify its use as a safety controller, because a standard commercial PC is unlikely to give acceptable confidence. However, most safety-related advisory systems do not require such a high level of reliability in the hardware. Most advisory software will be intended to run on commercial-grade personal computers on the HSE corporate network. Other programs (e.g. CPU-intensive modelling calculations) may require a high-end PC or a specialised workstation. The lower performance commercial-grade PC is the most likely to contain design and construction compromises, and is likely to be the least reliable, and is therefore the limiting case when considering whether or not the hardware is reliable enough to support advisory software safety functions. The SIL 1 or SIL 2 safety performance (see Appendix 3) is modest, most hardware failures will be revealed as gross program misbehaviour, and most failures will result in no result at all being provided to the user. In short, hardware faults will not mislead the user into a dangerous decision, and a PC or similar unspecialised commercial computing hardware has sufficient safety integrity to support the advisory software safety functions. From this point onwards, it is assumed that developing a safety related software advisory system to IEC is entirely an exercise in software. However, at the start of every new development, or major modification of an existing system, it must be verified that the assumptions of the Appendix 3 SIL assessment still hold. If yes, then this must be explicitly recorded in the project records. If no, then the hardware safety integrity requirements must be reviewed, and the safety integrity of the proposed hardware must be explicitly assessed if necessary. 3.3 THE IEC SAFETY LIFECYCLE The safety lifecycle is a systematic approach to ensure that all necessary operations have been carried out to guarantee that the safety related system has achieved the required functional safety. The scope of IEC is much wider than software advisory systems, so the stages of the safety lifecycle need some interpretation in this narrower context. This interpretation would normally be carried out as part of the management of functional safety (see IEC , clause c) when developing a new safety related system, but is done here generically for the whole class of safety-related software advisory systems for which Appendix 3 is valid. The general IEC scheme has 3 broad steps: the overall step makes decisions that precede the choice of hardware and software options. Some, but not all, of the overall considerations are pertinent to advisory software. the E/E/PES step makes decisions that relate to safety issues arising from the hardware of the safety related system. Most of these decisions can be neglected for advisory software where the only hardware in question is typically a commercial PC. the software step makes the decisions that relate most strongly to the safety of advisory software. 8

18 3.3.1 The "overall" decisions IEC , Concept, and Scope definition The overall scope of the advisory system consists of the physical hazards on which advice is sought, and the regulatory or societal value of the advice. Clearly, the advisory software must incorporate a competent understanding of the physical hazard and of the precautions that are considered adequate. But the resultant advice may well be influenced by non-technical factors. For example, a program to model the dispersion of a toxic plume might contain a definition of risk contours and consultation ranges which reflects legislation and official regulatory policy. IEC Hazard and risk analysis The primary concern with an advisory system is that it might be misused or misunderstood and thus contribute to an unsafe decision. The foreseeable circumstances of use and the mitigating factors are taken into account in the hazard and risk analysis (Appendix 3) for the whole class of safety-related software advisory systems. It is not necessary to repeat this assessment on every new system development or change, but each time it must be checked that the generic assumptions are still valid. It is envisaged that this check will be primarily the responsibility of the HSE staff who commission the development, and the developer will not normally be involved in this high-level risk analysis. But the developer must ensure that this check has not been neglected. An obvious opportunity to do this is at requirements review stage of the developer s Quality Management System. IEC Overall safety requirements The overall safety requirement specification consists of the safety functions and their required SIL. the fundamental safety function is that the advisory system must not give misleading advice that contributes to an unsafe planning decision. this safety function must be achieved with the SIL indicated in section 2.3. Later in the development process when more design information is available, it will be helpful to break down this overall safety function down into sub-functions specific to the design of the system, which can then be linked to safety requirements. Examples include: security restrictions to ensure the integrity of critical data; ergonomic interface design to avoid misleading users; a calculation technique that possesses specific mathematical characteristics. IEC Safety requirements allocation All safety requirements relate specifically to the advisory software. Any risk reduction that depends on non-software mechanisms has already been accounted for in the risk assessment. For example, it is not required to balance software design against fail-safe hardware to achieve safety. IEC Realisation No hardware will be developed or modified to accommodate the advisory software. All realisation issues will be addressed in the software-specific decisions. IEC and other technology, and external risk reduction Not relevant to advisory software development. All non-software contributions to risk reduction have been taken into account at the hazard and risk analysis. The only remaining reductions depend entirely on software integrity. 9

19 IEC and Planning for, and doing overall installation and commissioning Installation of the safety related software will usually have no special requirements beyond the usual procedures for adding new software into a stand-alone PC or network server. Where the software is developed on a non-pc host or on an operating system other than the HSE corporate standard, there may be host/target problems to resolve before the software can be installed. It may be necessary to plan installation procedures and acceptance tests when the advisory software is to execute on the HSE corporate network, which is managed according to certain rules and constraints (e.g. on the consumption of resources, or the generation of network traffic). HSE must make these and similar requirements known to the developers. However, in practice HSE may find it very difficult for technical and organisational reasons to state these requirements precisely. The developer should expect to show flexibility here, possibly by delivering progressively more complete prototypes which can be tried out in the HSE operational environment. The developer must understand clearly that the final software is acceptable only if it executes satisfactorily in the HSE operational environment. IEC Planning for validation, and Overall safety validation The acceptance procedures must ensure that the delivered advisory system has achieved its required functional safety. No special provision is needed at this overall stage. This will be addressed later in the software-specific decisions. IEC , , Planning for, and doing operation and maintenance No special provision is needed at this overall stage for operating, maintaining or modifying the software. This will be addressed later in the software-specific decisions. IEC Decommissioning Two aspects of decommissioning advisory software are relevant: removing the program from the hardware environment where it is executing. ensuring that all users who have received the program are warned to take it out of use. The first item will depend on technical aspects of the software design and implementation that will be fixed during detailed design and development. The question is: would de-installing the software in any way prevent the remaining programs from working, or would there be an unacceptable impact on network performance? Some thought at the design and development stage needs to be given to de-installing, but it seems unlikely that this will raise any special difficulty. No special provision is needed at this overall stage. The second item is best seen as an administrative obligation on the distributor of the software, and not as a technical obligation on the software developer. HSE as owner of the software may make a separate agreement with the developer to distribute the software and to manage any upgrades and bug-fix releases. If the developer also undertakes a distributor role, this will best be done as part of the software quality management system, see later in the software-specific decisions. No special provision is needed at this overall stage The "E/E/PES" decisions IEC is redundant for safety related software advisory systems: all safety functions are allocated to the software, so no hardware vs. software architecture issues arise. 10

20 the main hardware integrity concerns of IEC (i.e. sensors, actuators, special purpose computers, plant and equipment under control) do not arise. commercial PC or similar unspecialised commercial computing hardware has enough safety integrity for the safety functions of advisory systems. there is no significant activity to integrate software and hardware, other than the usual activities of installing, loading and activating a program. the only development activity is for software, and the safety validation is addressed in the software-specific decisions, below The "software" decisions IEC Software safety requirement specification No safety requirements relate to hardware. All safety requirements relate specifically to the advisory software. All risk reduction depend entirely on software integrity. The starting point for is the overall safety requirements specification, namely: the fundamental safety function is that the advisory system must not give misleading advice that contributes to an unsafe decision. this safety function must be achieved with the SIL indicated in section 2.3. In addition to the above general statements, it will be the responsibility of HSE to point out any design constraints (e.g. the need to use a particular peer-reviewed calculation procedure) or special sensitivities (e.g. verification of critical data) that give rise to software safety requirements. Attention will be needed to the characteristics of the advisory software outlined in section 1.2 above. For example, a delay in delivering a result may detract from the userfriendliness, but will not normally be safety-related. In practice, all this information will be contained in the normal functional specification for the operational behaviour of the software. HSE will write this functional specification, possibly with the assistance of a suitably expert software developer. For example, HSE might request the developer s expert advice on suitable programming techniques to minimise numerical error. The extent of this collaboration will depend strongly on the level of abstraction with which HSE states both the safety and the functional requirements: the more abstract, the better the distinction between the roles of HSE and the developer. The final responsibility rests with HSE to ensure that the specifications have been validated using methods in accordance with IEC The software developer must to review the software safety requirements specification (see IEC , ), probably in the requirements review stage of his Quality Management System. HSE domain expertise might be needed during software development to collaborate in reviewing software safety requirements. See IEC , Hazard and risk analysis. IEC , 7.7, Planning and doing software validation, software verification IEC adopts the widely accepted interpretation of V&V: validation is doing the right job, while verification is doing the job right. The validation of software functional safety confirms that each safety function describes the behaviour that will effectively address the safety hazard, and at an appropriate SIL. See IEC clause for examples of validation questions. But in practice software 11

21 validation has a significant degree of verification. This reflects the reality that the main safety requirements have been decided - and validated - before software development begins, and it s unlikely to be appropriate to revisit the fundamental system thinking at the relatively late stage of software development. However, for compatibility with IEC 61508, the term validation will continue to be used here. The validation of software functional safety must not be an ad-hoc activity towards the end of the software development, but must be explicitly planned. In practice it is to be expected that the final details of functional and other acceptance test criteria may not be available until software development is far advanced, but general plans can be made independent of software progress: the identity, competence and independence of the assessor; whether present or absent during testing; agreed methods of verification (e.g. analytical, statistical), tools and test environment; identifiable software modules and subsystems; pass/fail criteria (if available in detail). Documented results of software safety validation must clearly state either (1) that the software has passed the validation or (2) the reasons for its failure. HSE will usually delegate responsibility to the developer for detailed safety validation planning, for execution of the safety validation, and for presentation of the evidence of satisfactory performance. Depending on the complexity or criticality of the development, HSE may wish to guide the high-level safety validation planning, or take an active part in assessing the evidence of satisfactory performance. A safety validation plan could usefully contain a summary matrix of safety claims against supporting argument/evidence. This would indicate how the planned activities will give confidence that the development meets its required SIL, and would contribute to the safety justification documentation described below. IEC , Software modification Maintenance is a misnomer for software. IEC software is never maintained (in the sense of restoring a worn physical component to its as-new condition) but only modified, either to implement some functionality which has previously been implemented incorrectly, or to meet new requirements. Changes to requirements will originate from HSE, and will be implemented by the developer. Bug-fixes and point releases of software may be necessary after some operating experience. It is notoriously easy to introduce new bugs while fixing old ones and generally making software changes. In all cases, the developer s procedures for managing modifications must ensure that the software change does not cause the performance of the software safety functions to fall below the safety requirement. The impact of a proposed change must be assessed. A minor code correction may require only the source code to be considered; a major change may require the overall design to be reassessed; a change in functional requirements may require a new hazard and risk analysis. In general, earlier phases of the safety lifecycles must be repeated as necessary. IEC Hardware and software integration Installing the advisory software will usually have no special requirements beyond the usual procedures for adding new software into a stand-alone PC. In the more complex environment of a network, significant acceptance tests may be needed to demonstrate the software observes the relevant rules and constraints (e.g. on the consumption of resources, or the generation of network traffic). HSE staff will normally test this before formally accepting the software. 12

22 IEC Software design and development general The software developer should adopt a design for safety approach, where specific design features are adopted to mitigate identified vulnerabilities. These features might include: provide diverse display of the results, e.g. through a graphical interface and hard copy printout. provide a defence against the use of stale data by indicating when input values have been read by the program (e.g. by changing the colour of data values on a graphical interface). encourage the user to carry out a sanity check by designing the interface to prompt the user to do a rough calculation to check the result. use an interval arithmetic approach. This involves carrying two or three sets of values through critical calculations: the real data and data perturbed slightly from the real data. Comparing these values at the end will identify software and hardware problems due to numerical instability, singularities, etc. IEC Software design and development - development lifecycle The IEC approach to software design and development adopts a staged development model that incorporates widely recognised good practice. The development model recognises the reality that a strictly "waterfall" development is often impractical. For example, a specification may be less than 100% complete before the next stage of work starts. The requirement is (see IEC clause ) that all information from phase N of the software safety lifecycle that is essential to allow the next phase N+1 to proceed correctly (but possibly not to completion) shall be available, and shall be verified (i.e. in the usually accepted sense of phase verification - the outputs are consistent with the inputs). IEC Software design and development - software reuse A particular requirement of the software architecture phase is that attention must be given to the use of pre-existing components, packages, and operating systems: whether they have been previously verified and under what conditions, and their impact on the functional safety of the advisory software system. A similar requirement applies to software tools (language compilers, configuration management tools, automatic testing tools, etc.). It will be the developer's responsibility to show that the safety related software advisory system achieves the required functional safety. In some cases the developer may have the opportunity to consult the supplier of the package or tool to gather the required evidence. Note the distinction between merely pre-existing and pre-existing and also proven-in-use. A pre-existing package or component can be regarded as proven-in-use only when there is adequate documentary evidence, based on previous specific use, to demonstrate that the likelihood of any failure due to systematic faults is low enough to achieve the required safety integrity level of the safety function in which the package is reused. In short, it is not sufficient to claim that operating system X is suitable for a safety related application because several million copies have been sold over the years. Criteria which should normally be applied to components, tools etc. for the development of SIL 2 advisory systems include: have been in use for several years; have a maintained list of errors and problems reported; have a short list of outstanding issues relevant to the development; 13

23 (preferably) have been used successfully on previous safety related developments. This can be augmented with operating experience in the developer s organisation, information from an established user base or reference site, and more general information about the package (e.g. from the technical media, internet and so on). Extensive practical advice on reusing software components and tools in an IEC development is given in recent HSE publications which can be downloaded free of charge: C.Jones, R.Bloomfield, P.Froome, P.Bishop, Methods for assessing the safety integrity of safety-related software of uncertain pedigree (SOUP), HSE Books, ISBN , summarises the evidence that is likely to be available in practice to assess the reused software. P.Bishop, R.Bloomfield, P.Froome, Justifying the use of software of uncertain pedigree (SOUP) in safety-related applications, HSE Books, ISBN , considers how the available evidence can be used within the IEC safety lifecycle. IEC Software design and development - selection of techniques For each of the software safety lifecycle phases, IEC recommends techniques appropriate for each of 4 defined safety integrity levels. Selecting techniques from the list of recommendations does not guarantee by itself that the required safety integrity will be achieved. Relevant considerations include: the consistency and the complementary of the chosen methods, languages and tools; the developer s understanding of and competence in the chosen methods, languages and tools. The developer should choose techniques which are appropriate to his working procedures, company internal standards, or level of technical expertise. Some techniques are classed as "highly recommended" for a stated safety integrity level. If the developer chooses not to apply any of the recommended techniques, then he should document for audit purposes the justification for an alternative. One valid justification would be to use the characteristics of the advisory system listed in section 1.2 above to argue that an IEC recommendation was not applicable. For example, recursion is typically not a problem in this class of advisory system, since a failure to provide a result is a fail-safe outcome. 14

24 4. PLANNING AND ASSESSING FUNCTIONAL SAFETY At the end of developing the safety related software, it must be clear that the required safety functions have been implemented and that the system will satisfactorily perform the required safety functions under all the specified conditions. This requires the development process to be managed ("functional safety management") in a way that makes available the required evidence. The evidence takes the form of documented requirements and specifications, and the developer's response to them (e.g. designs, test plans, etc.); test specifications and actual results; and an assessor s critical reviews of these items with a clear judgement on whether or not the required functional safety integrity has been achieved. This judgement on the fitness of the software ("functional safety assessment") is not restricted to the final stage in a sequence of development stages. Rather, the relevant evidence will arise at each development stage, and an assessment should be made of the result of each stage before building on those results in following stages. This detailed management depends on the particular stages (or more commonly "phases") in the chosen development lifecycle, and the procedures of the quality management system. The developer is expected to use (or adapt) the normal QMS procedures in the normal way that (say) a "waterfall" software development lifecycle requires the design stage to be verified (i.e. the stage outputs evaluated against the input requirements) before proceeding to the detailed implementation. To assess functional safety, the developer adopts the IEC safety lifecycle, decides where his chosen development lifecycle generates the evidence required by the safety lifecycle, and at each safety lifecycle stage verifies that the inputs and outputs meet the IEC requirements. In practice, the IEC software safety lifecycle very closely resembles widely accepted industry practice in development lifecycles, so there is nothing here to surprise an experienced developer. Note also that the influence of development tools needs to be taken into account e.g. simulators, compilers and translators at various levels of abstraction, configuration database manager, etc.. A trivial example would be the use of a word processor to prepare text specifications trivial, because it is easy to argue that the word processor output can be thoroughly checked independently of the quality of the processing software. More difficult examples would be the use of an optimising compiler that can alter execution control flow by short-circuiting condition evaluation, or a hot-spot analyser that inserts instrumentation code whose very operation alters the multi-task scheduling and possibly the behaviour of the multi-threaded program it is analysing. Although the detailed management and assessment of functional safety depend on the particular choice of development lifecycle, IEC imposes some general requirements on management and assessment: the assessment evidence must be gathered in a systematic way, using some well defined procedures, but not necessarily a 3 rd party certified quality management system. 15

25 the individuals, department or organisation carrying out the assessment must be identified, their competence to do the job must be demonstrated, and there must be a clear allocation of responsibility. the assessors must be appropriately independent of the developers so as to take an objective view of how well the software safety functionality has been achieved. For SIL 1 and SIL 2 systems, assessment by an independent department within the developer s organisation will be sufficient according to IEC Table 5. Where a sufficiently independent department with the necessary expertise does not exist, independent assessors may need to be sought outside. there must be procedures for recording assessment recommendations and resolving faults, and for imposing effective configuration management and change control. the overall assessment activity must be systematically planned rather than ad-hoc, and the success criteria must be clearly stated for each assessment of a safety lifecycle stage (or group of stages together, it that can be adequately justified). 16

26 5. SOFTWARE QUALITY MANAGEMENT The advice in this document is of interest to software developers with quality management systems at a variety of levels of sophistication, from a national/multinational to a small software house or a single specialist programmer. It is essential to note that this document does not outline the software developer's quality management system, and is not a draft list of quality procedures. IEC lists the requirements for justifying the fitness for purpose of the safety related software systems. These requirements must be addressed at some point in whatever quality management system the developer adopts. IEC does not tell the developer how to organise the quality management system nor how to set up procedures. Rather, IEC lists the goals that must be achieved during the course of the safety related system development. It is then the task of the software developer to set up a suitable quality management system that controls the software development and shows how/where/when the developer's working practices deliver the required evidence of fitness for purpose. The requirements (see above, "Planning and assessing functional safety") on management and assessment of functional safety apply generally to the development of a safety related system rather than specifically software developments. However, IEC also places some specific requirements on software quality management. It is not obligatory to have a 3 rd party certified QMS. ISO 9000/Tickit and similar is not mandatory. The requirement (see IEC , 6) is that it must be possible to audit to show that all necessary operations have been carried out to guarantee that the required software safety integrity has been achieved. But note also the practical consideration that if the fitness of a safety related advisory software system is subsequently challenged, and if the developer and/or HSE appeal to the development audit trail as evidence of fitness, then the credibility of the developer's quality procedures will be important, and the developer's unsupported claim that the procedures are adequate might be unconvincing. In short, a developer setting up a new QMS to meet IEC requirements would be well advised to consider getting on record some competent and independent view that the QMS is adequate. One way of assessing a QMS is by the defences it provides against typical software failures such as: inconsistency or incompleteness of requirements failure of specification to capture requirements failure of design to implement specification failure of code to realise design fault in operating system, run-time system or hardware error in transcription of data to disk, PROM, etc. failure of development tools The QMS must provide effective configuration management and change control. Configuration items include at least the following: safety analysis and requirements; software specification and design documents; software source code modules; test plans and results; preexisting software components and packages that are to be incorporated into the safety related advisory software system; all tools and development environments which are used to create or test, or carry out any action on, the safety related advisory software system. 17

27 Note the need to maintain the configuration of development tools. However, it is recognised that it may not be practical to retain the tools used during initial system development for the whole lifetime of the system. Effective change control procedures must prevent unauthorised modifications; must analyse the impact of a proposed modification; and must clearly approve or reject the proposal. It must be possible to guarantee the composition of, and the building of, all software baselines (including the rebuilding of earlier baselines). Finally, there must be clear management authority to ensure that the QMS is in effective use. 18

28 6. DOCUMENTATION The purpose of documentation is to record and maintain the information which arises as system development proceeds, and which is necessary to manage the functional safety in a systematic and transparent way. Documentation also records the evidence needed to assess whether or not the required functional safety has been achieved. IEC compliant development should not generate any more documentation than is needed for the above purposes. It is information rather than physical documents that is of interest. The documentation format is not prescribed, and may be organised according to the developer s own established procedures. This information is acceptable in different forms (e.g. paper, film, or any data medium to be presented on screens or displays). If it happens that a developer already routinely records the information recommended by IEC 61508, then the extra documentation to prove compliance with IEC need consist only of a route map through the developer's existing quality management system, indicating where the evidence relating to each relevant IEC clause is to be found. It is advisable for a developer to produce a summary document (perhaps called a safety justification or a dependability case). It should contain: A summary of the safety claims for the systems. Typically these are: a high quality software engineering process; functional correctness; accuracy (the results are sufficiently accurate when calculated using finite-precision arithmetic, and numerical instability should be detected) security (appropriate steps are taken to prevent malicious and accidental changes to methods and data) modifiability (the chance of maintenance-induced errors is minimised) fail safety (there is a low probability of unrevealed failures) usability (the system makes it hard for users to make errors) A summary of the IEC compliant activities carried out, explaining how these provide evidence to support the safety claims. This summary can also be used to justify the inclusion or omission of techniques from the tables in Part 3 Annex A. 19