Issue Date:

16 June 2008

Review Date:

16 June 2012

Open Government Status:

Fully Open

Version no:

2

1 Purpose & Scope

1.1  This Technical Assessment Guide (TAG) addresses Safety Assessment Principle ¹ (SAP) ESS.27 which deals with the software of computer based safety systems (SSs). Technical Assessment Guide T/AST/003 addresses SSs in general. This SAP is supported by other general and plant specific SAPs.  Where a computerised SS is used, because the technology is inherently complex and not amenable to traditional methods of reliability assessment, SAP ERL.1 and SAP paragraph 177 should be applied¹.  ESS.27 presents the elements of a multi-legged procedure that should be used to demonstrate the adequacy of a SS using software based technology which is based on SAP ERL.1 and SAP paragraph 177.

1.2  The TAG contains guidance to advise and inform ND inspectors in the exercise of their professional regulatory judgement. Comments on this guide, and suggestions for future revisions, should be recorded on the appropriate registry file.

2 SAPs addressed

2.1 Key  principles

There is only one key principle that deals specifically with this topic, ESS.27. It is, however, underpinned by two more general principles, ERL.1 and ERL.2. The content of ESS.27 is reproduced below for ease of reference.         

Engineering principles: safety systems	Computer-based safety systems	ESS.27
Where the system reliability is significantly dependent upon the performance of computer software, the establishment of and compliance with appropriate standards and practices throughout the software development life-cycle should be made, commensurate with the level of reliability required, by a demonstration of ‘production excellence’ and ‘confidence-building’ measures.

2.2  Supporting principles

The key principle is supported by a number of other principles of relevance to computer based SSs.  The SAPs identified below are explicitly referenced in the main body of this TAG.  Other SAPs are implicitly referenced in Appendix 1 (e.g. A1.1 to ESS.18 and A1.2 to EDR.4).  Note that T/AST/003 ‘Safety Systems’ addresses the generality of SS SAPS (e.g. ESS.1 to ESS.27).

1. EKP.3  Defence in depth.
2. EDR.2  Redundancy, diversity and segregation.
3. ECS.1  Safety categorisation.
4. ECS.2  Safety classification of structures, systems and components.
5. EDR.3  Common cause failure.
6. EDR.3  (paragraph 172) Common cause failure/limitation placed on the system.
7. ECS.3  Standards.
8. ERL.1  Form of claims.
9. ERL.2  Measures to achieve reliability.
10. ERL.4  Margins of conservatism.
11. ESS.21  Reliability.
12. MS.1, MS.2, MS.3 and MS.4  Leadership and management for safety.
13. ECM.1  Commissioning testing

3  Relationship to licence and other relevant legislation

3.1  Licence conditions 14 and 15 (preparation and review of safety cases) apply particularly, and Lcs 17 (Quality Assurance), 20 and 22 (modification), 27 (safety mechanisms, devices and circuits), 28 (examination, inspection maintenance and testing) are also relevant.

4  Advice to assessors

4.1  General

1. The need to use computer based SSs should be justified since their inherent complexity means that demonstrating they are adequately safe is difficult (ESS.21).  Ideally where diverse SSs are required, and one is computer based, the second one should be provided using a non-computer based system (EKP.3, EDR.2 and EDR.3).  The topic of diverse computer based systems important to safety is addressed in Appendix 4.
2. The advice presented below outlines the muti-legged procedure philosophy, production excellence demonstration and confidence building elements, and sources of further guidance. For any production excellence or confidence building element the licensee has the option of non-compliance provided a satisfactory case can be made.
3. Assessors should ensure that the projects’ safety management system (MS.1 to MS.4) is adequate for the needs of producing and building confidence in a computer based SS. The organisational arrangements should clearly define roles and responsibilities.  The competence of those involved should be demonstrated and adequately managed ¹⁵.

4.2  Multi-legged procedure

1. In general the level of dependence on SSs incorporating complex technology should be limited to the order of 1E-1 failures per demand, unless a sufficiently robust justification can demonstrate the appropriateness of a lower value.  The application of SAP ESS.27 to computer based SSs is a means of demonstrating the appropriateness of a lower value (i.e. lower than the “order of 1E-1 failures per demand” which is interpreted herein as 0.3 failures per demand or lower).  However, with current techniques and taking all relevant factors (see Appendix 3) such as complexity into account, a probability of 1E-4 failures per demand is the best that can justifiably be claimed for computer based SSs ², ⁴, ⁹, ¹⁰ (EDR.3 (paragraph 172), ERL.1 and ERL.2).  Future advances in software engineering techniques could lead to a situation where a strong case could be made for a lower figure.  Such a case would not then be ruled out of consideration.

1. Assessors should be wary of attempts to reduce a fault sequence frequency through risk reduction claims involving multiple low integrity computer based SSs (ERL.4). The concern is that inappropriately large amounts of credit may be claimed in total by combining several small amounts of risk reduction, the effects of such combination often being hidden within what is called the initiating event frequency value.  Although functionally such low integrity systems are SSs in these circumstances they are usually embedded in other large systems that are classified as safety related.  Unless the claim for all contributing ‘risk reduction’ elements of safety related instrumentation (SRI) taken together in a given fault sequence is clearly pessimistic, and not better than of the order of 1E-1 failures per demand in total, the separate SRIs should be treated as though they were SSs and assessed as such.  Where such SRI is identified and the claimed risk reduction is 0.3 failures per demand or lower then they should be subjected to ESS.27. 
2. Assessors should consider whether it is desirable to apply ESS.27 to computer based SRI such as control systems.  Each separate computer based SRI that requires a reliability claim of better than of the order of 1E-1 failures per year, interpreted herein as 0.3 failures per year or lower, should be subjected to ESS.27.
3. ESS.27 has two key legs, production excellence demonstration and independent confidence building ¹,⁵ and ⁶. The philosophy of the multi-legged procedure is that system acceptance centres on the demonstrated high quality production and an independent searching examination of the systems’ fitness for purpose that finds no significant number of errors.

1. Where the confidence building activities reveal a significant number of software errors the quality of the production process is brought into question and the argument for system acceptance is weakened. Any remedial action must go further than software error correction, the licensee must restore confidence in the system by thoroughly examining the production process to establish that similar errors have not arisen elsewhere. The licensee must then demonstrate that the corrected software is fit for purpose by a sufficient repetition of the confidence building measures.
2. The production excellence and confidence building elements are outlined in sections 4.3 and 4.4. Judgement will be required in determining the detailed scope and rigour of the elements (including applicable techniques and measures) as informed by the category of the functions implemented by the system, the systems’ classification and its integrity requirements (ECS.1, ECS.2 and ECS.3).  Guidance may be obtained from standards ⁸ on the techniques and measures applicable to defined integrity levels and this topic is discussed further in Appendix 3.  The procedure should be underpinned by a comprehensive review of issues taking account of past precedents ⁵/ and ⁶ (ERL.1).

1. When considering past precedents assessors should note that the position of techniques and measures in the production excellence and confidence building legs is not immutable.  Increasing the strength of one leg might lead to a reduction in requirements for the other; but both legs need to be sound.
2. Early agreement of the safety case elements including the applicable techniques and measures should be sought with the licensee.  Following agreement the target should be to retain the fixed status of the agreed set for the projects’ duration.  Nevertheless, if some relevant technology were to emerge with significant potential to improve real plant safety then this would become subject to consideration, in terms of its ‘reasonable practicability’, for adoption.

4.3  Production excellence

1  The multi-legged procedure requires a demonstration of production excellence, covering initial specification through to the finally commissioned system, comprising the following elements:

1. Thorough application of technical design practice consistent with current accepted standards for the development of software for computer based SSs e.g. ⁷ (ECS.1, ECS.2 and ECS.3);

1. Implementation of an adequate quality assurance programme and plan in accordance with appropriate quality assurance standards (ECS.3 and A1.27 to A1.29);
2. Application of a comprehensive testing programme formulated to check every system function (ECS.3), including:
   • prior to installation on site, the verification of all phases of the system production process and the validation of the integrated system against its requirements specification by persons qualified for the task and not involved in the specification and design activities
   • following installation on site, a demonstration that the safety system, in conjunction with the plant, performs to requirements, this demonstration being devised by persons other than the system specifiers, designers or manufacturers,
   • the use of prototypes as appropriate,
   • a programme of dynamic testing, applied to the complete system, which is capable of creating confidence that the system meets its reliability requirements.

NB. Text in clauses a), b) and c) above that is identical to that contained in SAP paragraph 360 is identified by bold.  

2  Excellence of production requires that the best practices current at the time be used to avoid errors, detect and remove those not avoided and provide in-built system tolerance to those not detected (ECS.3 and EDR.1). It is important that an unambiguous, comprehensive and verified specification of the system requirements, covering the full system life-cycle is available from the earliest stages of the production process.

3  Should the production excellence assessment identify weaknesses in the production process, compensating measures should be applied to address these. The type of compensating measures will depend on, and should be targeted at, the specific weaknesses found (ESS.27 paragraph 362). Compensating measures should not be confused with the confidence building activities discussed below. The confidence building activities should be determined at the outset of the project and applied as far as possible to the final production software (i.e. after the completion of any compensating measures).

4  Although not mandatory, the case for production excellence is greatly assisted by evidence of the systematic application of national and international e.g. ⁷ standards, coupled with a case by case justification of non-compliances.

5  It must be demonstrated that the integrated equipment is capable of satisfactory operation in situ through an extensive pre-operational test (A1.87).  During this stage the equipment will be operational (with frequent testing) while being progressively integrated with other plant as part of commissioning (ECM.1).

6  It is recognised that the dynamic testing could be part of the confidence building measures if not undertaken by the manufacturer. The number of dynamic tests should be informed by statistical testing considerations. This might mean that tens of thousands of tests are required for confidence in the dependability of the system to be built up (e.g. of the order of 50,000 tests with no failures for a 1E-4 probability of failure on demand demonstration to 99% confidence). Consideration should be given to the feasibility of generating a statistical estimation of system reliability (as informed by research).

4.4       Confidence building

1  The confidence building leg provides an independent and thorough ‘reasonably practicable’ assessment of the SSs’ ‘fitness for purpose’ (ERL1), comprising the following elements:

1. complete and preferably diverse, checking of the finally validated production software by a team that is independent of the systems suppliers, including;
   • independent product checking providing a searching analysis of the product including application of static analysis (A1.75) and other techniques such as reverse engineering and desk-top review,
   • independent checking of the design and production process including all activities needed to confirm the realisation of the design intention such as interpretation and adequacy of the specification, application and compliance with design specification, methods and standards; and
2. independent assessment of the test programme, covering the full scope of test activities (e.g. verification, validation, commissioning and dynamic testing) including traceability of tests to specification and confirmation that the specification is met.

NB. Text in clauses a) and b) above that is identical to that contained in SAP paragraph 361 is identified by bold.  

2  The independents should determine and justify their approach, the rigour of which should be proportional to the needs of the task. Wherever practicable the independent assessors should employ checking methods dissimilar to those used by the systems producer(s) (e.g. Dynamic Testing, MALPAS etc. as applied to the Sizewell B PPS).

3  The chosen confidence building techniques should be demonstrated to be adequate prior to application. New and unproven techniques will need especially comprehensive demonstration in order to provide confidence that the route chosen will be successful.

4  It is important to stress that the product checking should be applied only to the finally delivered product - that is after completion of the manufacturers verification and validation. The licensee may, however, be able to make a case for applying techniques to code that has completed the manufacturer’s independent verification.

5  The timing of the confidence building activities should ensure that their application and correction of findings does not become entwined with the production process. The conduct of the initial proving of confidence building techniques should not compromise the assessment of the delivered product.

6  The confidence building measures should be conducted by suitably qualified and experienced persons who are independent, established in a working regime compatible with the objectives of the task and free from conflicts of interest.

7  The use of “independent” should be interpreted as meaning not connected with the systems’ suppliers, either designer or manufacturer. The organisational arrangements including allocation of responsibility for confidence building tasks to the licensee’s procurement group (i.e. the intelligent customer group for the system) and to independent assessors in a different line management chain should be justified.

8  The independents who are separate to the licensee’s procurement group should have financial autonomy and managerial independence to reach their own conclusions on the adequacy of the system and its safety case.  They should not be restricted in technical scope and have a frank reporting regime with a route to the licensee’s main Board.

9  The independents should report findings and their reconciliation within the safety case. All reporting of confidence building measures including findings and their reconciliation within the safety case should be auditable.

4.5  Technical guidance

1  Technical guidance can be found in Appendix 1 which is a record of an earlier detailed technical assessment guide.  The guidance provided in Appendix 1 should be used in conjunction with the later IAEA Safety Series ² guidance, European Commission guidance document ³, the report “Licensing of safety critical software for nuclear reactors. Common position of seven European nuclear regulators and authorised technical support organisations – Revision 2007 [736KB]” and IEC standards as appropriate (see below).  The term “protection systems” is used in Appendix 1, however, the guidance is also applicable to other SSs and SRI containing software falling within the scope of ESS.27. 

2  Technical guidance and regulatory advice is available in the IAEA Safety Series 2, a European Commission guidance document ³ and the report “Licensing of safety critical software for nuclear reactors. Common position of seven European nuclear regulators and authorised technical support organisations – Revision 2007 [736KB]”.  In particular, they contain guidance on a number of topics not fully addressed or considered in the earlier assessment guide (Appendix 1), such as; use and validation of pre-existing software, computer security, use of tools, software diversity, safety demonstration and formal methods.  Assessors should ensure that the recommendations and guidance of these documents ², ³ and ¹³ have been considered. While they are directed at Nuclear Power Plants much of their content is applicable to other nuclear facilities.

3  Further technical guidance can be found in IEC standards such as IEC 60880 ⁷ (for software of SSs), IEC 61508 ⁸ (grading of techniques and measures for software development - see Appendix 3) and IEC 61513¹¹ (general requirements for systems).  The IEC standards should be consulted for topics not addressed by the guidance provided by Appendix 1, the IAEA Safety Series[2], the European Commission guidance document ³, or the report “Licensing of safety critical software for nuclear reactors.  Common position of seven European nuclear regulators and authorised technical support organisations – Revision 2007 [736KB]”.