HSE banner

Computer based safety systems - technical guidance for assessing software aspects of digital computer based protection systems

T/AST/046 - Appendix 1


A1.1  Computer systems provided as part of the protection system should not be used to perform non-protection functions.  Specifically, control functions and the protective actions claimed against their failure should not employ common hardware or software.

A1.2  The single failure criterion should be applied to all parts of the protection system including both the systems and applications software of the computer based part. Where the application of this principle leads to a requirement for diverse software in an otherwise redundant system then arguments in support of applying a high quality single software solution can be considered, since high quality (see Para A3.4) means that the software is not the determinant of system reliability.

A1.3  Computer based protection systems should be specified, designed, manufactured, tested, installed, commissioned, operated and maintained in an orderly, disciplined and coherent manner. When carrying out the assessment clear evidence should be sought that best available practice has been used, e.g. structured design methods, software modularised, each phase verified, clear documentation, auditability and validation testing.


A1.4  Only reputable companies should be used in all stages of the lifecycle of computer based protection systems.  Each should have a demonstrably good track record in the appropriate field. Such companies should only use staff with the appropriate qualifications and training for the activities in which they are engaged. Evidence that this is the case should be provided.

A1.5  The licensee should ensure that the appropriate standards, procedures and personnel are used at all stages in the software lifecycle to produce the required integrity for the computer based protection system. Those persons carrying out this Safety Authority role should be independent from the designers, implementors, the verifiers and validators.

A1.6  The Safety Authority should submit written proposals to NII on the methods to be employed to demonstrate how the required level of integrity will be met. Regular progress reports should be submitted throughout the software development lifecycle.

A1.7  For all stages of the software lifecycle the verifiers should be independent from the designers and implementors. All communication between the two groups should be recorded in writing; unrecorded verbal communication should not be allowed.  Such communications should be logged and archived to provide an auditable trail and ensure that system concerns, together with their resolution, are clearly and accurately documented. 

A1.8  The validators should be independent from the team producing the requirements specification. All communication should be recorded in writing; unrecorded verbal communication should not be allowed. The validation team should review the specification for correctness and completeness, and should devise and implement the test strategy that demonstrates that the system meets its specification.

System specification

 A1.9  A requirements specification should be produced that specifies what is required of the system but does not contain any information on how the specification is to be implemented.

 A1.10  Where practicable the requirements specification should be animated through the process of executing the specification.  Animation aids the process of communicating ideas about a complex set of requirements which should be understood by all professionals involved in the protection system project.

 A1.11  The specification should list standards to be used for all aspects of the software lifecycle. All non-compliances should be justified. The standards listed in the Paragraph A1.27 and Reference 7 are currently regarded as appropriate for the development of protection system software. Their exclusion from the specification should be justified.

 A1.12  Credit can be claimed for the use of a formal mathematical specification language since this will increase confidence in the correctness of the design and also assist in the static analysis phase. The language used should have well defined syntax and semantics that allow logical reasoning about the specification. The specification should be validated by logical reasoning and peer review of that reasoning if credit is to be claimed for the use of a formal mathematical specification language.

A1.13  Timing budgets, volumes of data, data rates, peak data loads, maximum values of parameters and calculation accuracies should be specified.

System design

 A1.14  The system should be designed using a structured approach so that the design process is clearly visible. Designs that facilitate software analysis are preferred. For example, the essential safety kernel should be securely separated from other features such as hardware failure diagnostics and operator communications. Concurrent interactions with other systems should be avoided.  Also, the provision of software for the detection and reporting of hardware failure should not be allowed to complicate the system.

 A1.15  For a project involving software of any large size or complexity, Computer Aided Software Engineering (CASE) tools should form an integral part of all stages of the software lifecycle.

 A1.16  Due consideration should be given to the frequency of sampling of input parameters such that varying measurements are truly represented within the system and events are observed within sufficient time to take the necessary action.

 A1.17  The system as a whole should be designed as far as practicable to reveal failures. Diagnostic software can be used to detect hardware failures (see section on "Hardware Fault Monitoring").  Defensive programming techniques and special hardware such as watchdogs, divide-by-zero interrupts etc. can be used to detect software failures. Hardware failures which are not self-revealing should be deemed to exist until the next proof test that would reveal them.  These proof tests should be defined.

 A1.18  Facilities should be incorporated for an operator to determine the state of each input variable and output function.

 A1.19  The program should include a test arrangement to enable in-service functional checks of the system hardware to be made from the input variables to the output action. A frequency for applying this test should be proposed with a justification based on the type of faults detected and their rate of occurrence. The insertion or removal of any test equipment should not require manual action to reinstate the system; however, there should be confirmatory feedback to the operator.

 A1.20  The program together with its stored constants, should be stored in a secure, reliable and permanent manner such that timely automatic restart is possible following power supply failure or any such detectable and recoverable failure.

 A1.21  A system design aim should be to prevent the unintentional operation of a safety device due either to operator error or to a fault in the equipment.

 A1.22  Unsolicited changes in plant status should be detected and where possible prevented.

 A1.23   The need for manual intervention (e.g. for calibration or adjustment) should be kept to a minimum.

 A1.24  The use of features not specified by the manufacturers (i.e. undeclared instructions or clock rates) should be prohibited unless their use is fully justified.

A1.25  A systematic method should be used to identify critical system modules. Examples of such techniques would be Failure Modes and Effects Analysis (FMEA) and Fault Tree Analysis (FTA).

 A1.26   Failure of one part of a redundant scheme should not adversely affect other parts of the system.

Quality assurance

 A1.27  Quality Assurance should be at least to the standards and guidance defined by the following documents.

  1. BS 5882:1980: Specification for a total quality assurance programme for nuclear installations.
  2. IAEA Safety Series No. 50-C/SG-Q : Quality Assurance for Safety in Nuclear Power Plants and other Nuclear Installations
  3. BS EN ISO 9001:1994 : Model for quality assurance in design, development, production, installation and servicing.
  4. IAEA: Technical Report Series No. 282, Manual on quality assurance for computer software related to the safety of nuclear power plants.

A1.28  An agreed Quality Assurance Programme and Plan for the hardware and software, covering all stages of specification, design, manufacture, installation, commissioning, operation and maintenance, should be available.  Attention should be given to organisational structure, error reporting and corrective action, computer media control (issuing and storage), testing, supplier control, record keeping and documentation.  Standards and procedures should be available for these aspects.

 A1.29  Periodic, independent audits should be conducted to ensure conformance to the QA Programme and Plan.

 A1.30   Procedures should be in place to ensure that the effects of modifications on all parts of the system are fully assessed.

Software configuration management

 A1.31  The software including all support software should be covered by a suitable, readily understood configuration management system (CMS) throughout the lifecycle. The system should be protected by a security system that prevents unauthorized access.  Users should only be able to access parts of the CMS for which they have authority. The security system should be designed to a high standard and be regularly reviewed for possible breaches. The system should not be linked to an off-site network.

A1.32  During all stages of the software lifecycle software should be stored in a secure place and the media clearly identified as to its status.  Strict procedures should be employed to ensure that the correct version is issued and that it has not been subjected to unauthorized modification either accidentally or intentionally. The issued version should be verified against a master copy.

A1.33  Version control and the issuing of correct versions requires the setting up of formal procedures.  All software copies should be clearly and uniquely labelled with at least title, version no. and creation date. Consideration should be given to the inclusion of the above data in the code so that this can be checked by the program.

A1.34  Program modifications should be controlled by change control procedures in which modifications are evaluated, approved and properly documented.  Access to the software should be strictly controlled so that a programmer cannot make an unauthorised change at any stage in the lifecycle (especially post V&V).


A1.35  Software reliability cannot be quantified with a high confidence level because it is associated with systematic events which do not lend themselves readily to statistical expression. Therefore, it is necessary for it to be produced to a standard such that it is considered not to contribute significantly to the overall unreliability of the system, allowing considerable margin for uncertainty. This means that only software produced to the highest standards should be employed.  Unfortunately, the contribution that each development and testing technique makes to the overall reliability of the software cannot be quantified but some intuitive guidance is given in Appendix 3.

 A1.36  Defensive programming techniques should be employed where known states and parameter ranges occur. For example, where the state of a valve can be either open or closed, a check should be made that, after a finite change-over time, one state or the other is achieved. This would be done by checking open AND NOT closed, or closed AND NOT open. In the case of parameter ranges, if the output of a temperature computation returns a negative result or an unrealistic answer then an error should be flagged.

 A1.37  Assertions should be inserted into the code and the system should be made as fault tolerant as possible. For example, data errors occurring in inputs and on transfer between modules should be trapped and alarmed; instrument readings should indicate when they are off scale; correct output address selection pre- and post-operation should be verified.

 A1.38  The system should be designed such that, where practicable, the correct operation of the output addressing system is verified. The design should also include means for checking that the final control element has achieved the desired state in the required time.

 A1.39  If complicated calculated protection functions are required the program should be written so that a simple function(s)  will provide an error check and back-up action.

A1.40  Because of the problem of unauthorised accessing via data links (hacking), computer based protection systems and all supporting systems should not be connected to off-site networks either directly or through another computer system unless an adequate safety case has been made to prove that there is no capability for unauthorised access to the protection system.

A1.41  It should be demonstrated that the protection system and all supporting systems are protected against unauthorised access. Password protection alone is insufficient.

A1.42  All support software and systems used in the production and testing of programs (compilers, assemblers, linkers, loaders, configuration control systems, static analysers, test harnesses, coverage analysers, etc.) should themselves be qualified or otherwise suitably justified.

A1.43  Programs should be organised on a modular basis, in a manner which minimises the chance of errors, facilitates independent verification (e.g. restricting the design of a module to one clearly identified function that requires only minimum interaction with other functions) and minimises the impact of changes. Modules should not exceed a limit specified for the system (e.g. 50 or 100 statements, or the amount of coding which can be placed on one page) without written justification.

A1.44  The program should run in a fixed sequence pattern and should not generally employ interrupts. Where interrupts are used they should be justified in terms of demonstrably simplifying the program. Their usage and masking during time and data critical operations should be checked for correct operation in-service and be well documented. The hardware and software should be designed to detect both unserviced and missing interrupts. All interrupt vectors should be initialised whether used or not. Unused interrupts should point to an error reporting procedure and should initiate protective action.

A1.45  Appropriately engineered facilities should be provided to ensure that operation of any testing facilities, manually or automatically initiated, should neither trigger spurious operation of tests, nor protective action nor degrade protective system reliability. Where testing causes inhibition of protective action, testing facilities should be regarded as part of the protection system and should be designed and engineered to the same standards.

A1.46  The system should employ a hardware watchdog of demonstrably adequate reliability. This should be serviced by a program operating at the base level of priority so as to detect problems such as programs locked in loops or deadlocks.

A1.47  On detection of failure the system should adopt a safe state and as soon as practicable report the condition to the operator.

A1.48  Careful consideration should be given to the power fail/restart procedures since initial conditions and phasing may produce an unsafe state in redundant systems

A1.49  The compiler of the programming language used to write the software should be validated, its error detection capabilities defined and the code restricted to a safe subset. The same version of compiler should be used on all the software. All software must be retested if a new version of the compiler is used, unless it can be demonstrated that the machine code has not changed. Any compiler code optimisation should be simple and provably correct. Also, the same optimisation options should be used on all the software. Array bound checking should be included.

A1.50  Assembler language should be kept to a minimum and subject to the same strict controls as a high level language. Good practices that would be introduced by a compiler should be implemented in assembler language, e.g. array index checking.

A1.51  Any proposed operating system should be shown to comply with this assessment guide.

A1.52  Coding standards should be mandatory and should as a minimum cover naming conventions, house style, level of commenting and software production procedures

A1.53  A high level, strongly typed, programming language that prohibits the unsafe mixing of variable types is preferred. Variables and data should be explicitly declared and assigned. The program layout should aid understanding. Assembler and machine code inserts into high level language code, and commands that allow direct memory manipulation should not be allowed.

 A1.54  The coding standards should prohibit the following practices:-

  1. Tricks, recursion (unless it produces simpler code than by other means), re-entrancy and unnecessary code compaction - it should be noted that recursion is not amenable to static analysis;
  2. Program halts - unless it is not possible to action (by bringing the plant to a safe state) and report the error;
  3. Dynamic storage allocation - causes problems with static analysis, since memory overflow and overwriting of variables cannot be checked;
  4. Dynamic instruction changes;
  5. Multiple use of variables - variables should not be used for more than one function;
  6. Default conditions in case statements - all cases should be covered, default should be failure condition;
  7. Multiple module entry points - single entry and return points should be employed (other than error return where required): where a module is a subroutine or procedure, parameter passing should be the means of conditioning;
  8. Branching into loops;
  9. Complicated calculation of indexes;
  10. Equivalence statements - especially referring to a COMMON or global area;
  11. Procedure names used as procedure parameters;
  12. Modification of loop control variables within the loop;
  13. Similar names for variables and procedures;
  14. Assembler and machine code inserts into high level language code;
  15. Direct memory manipulation commands - for example, PEEK and POKE in BASIC;
  16. Computed branching  (note that good program structure such as use of  IF-THEN-ELSE and CASE statements is required).

A1.55  The coding standards should encourage the following:

  1. Arithmetic expressions reflecting the equations they represent;
  2. Rate of change checking, where possible;
  3. Dynamic checking for overflow, underflow and compatibility between precisions;
  4. Transfer of data by parameter passing - the unnecessary use of global variables should be discouraged;
  5. Constraining of loop iterations to a declared maximum value (this ensures loop termination);
  6. Explicit initialising of all variables;
  7. Representing of constants by symbolic names;
  8. Meaningful variable names and types;
  9. Nesting limited to a maximum depth of four (4);
  10. Minimisation of procedure and subroutine parameter numbers (ideally not to exceed four (4));
  11. Careful use of indirect addressing so that the ultimate address is as clear as possible;
  12. The performance of arithmetic operations in binary fixed-point arithmetic, unless the use of floating-point arithmetic can be demonstrated to contribute to safety - in the latter case, the hardware and software used to implement floating point functions should be suitably qualified;
  13. Checking of computer array subscripts for dimensional range;
  14. Detailed commenting (see Paragraph A1.90).

A1.56  Programs and fixed data (including operational data) should be held in read only memory so that they cannot be changed on-line either intentionally or due to a software error. Changes to in situ ROM should be subject to strict controls to avoid incorrect data entry (program logic should NOT be changed in this manner); consideration should be given to the use of special error checking software within the protection system, and within the modification device for off-line use, to check the correctness of any necessary fixed data changes.

A1.57  All messages should be tagged with a serial number to enable the loss of a message to be identified.

A1.58  The protection system should automatically record, in a secure manner, all fixed data changes within the system for subsequent analysis.

A1.59  Protection system loading should be computed on-line and be available without requiring special procedures.

A1.60  The software should be subjected to static analysis by the designers. The static analysis tool should be of proven design, fully qualified and diverse from the static analyser used by the independent assessors.

Hardware considerations (software aspects)

A1.61  Since computer system components involve complex design with the potential for introducing errors, only proven components should be used.  Proof of suitability should include either evidence of extensive installation years free of design faults or rigorous formal proof of the design plus comprehensive type testing.

A1.62  Where redundancy is claimed the hardware should be physically and electrically segregated.

A1.63  Information transmission between redundant parts of a protection system should be avoided. Where this is not fully practicable then the system should be arranged so that malfunction of any redundant part does not adversely affect the other part

A1.64  Redundant portions of the system should not be operated synchronously unless it can be established that there are safety advantages in so doing.

A1.65  Hardware modules should be clearly labelled with a unique part number and serial no.  Also, the bin positions should be correspondingly labelled. Special precautions should be taken where modules are configurable; only reliable means of configuring should be used, e.g. soldering or wire wrapping. Features should be provided which detect (or prevent) the insertion of an incorrect module, absence of a required module or incorrect insertion of a correct module. Special attention should be paid to the prevention of the incorrect connection of cables due to either wrong orientation or location.

Hardware fault monitoring

A1.66  The memory should incorporate automatic (preferably hardware based) parity and checksum testing to detect bit change errors.  Attempts to write to read only or protected memory should be detected.

A1.67  Where possible, operations should be timed and an error indicated when the pre-set time for the operation is exceeded.

A1.68  Correct operation of analogue-to-digital converters should be checked by reading reference voltages.

A1.69  Communications messages should incorporate checksums and message lengths.

A1.70  At initialisation the system should check its ability to write to and read from all installed memory and address all required hardware modules

A1.71  Where possible, power supply voltage levels should be checked. Also, the ability of a signal line to perform its specified function should be tested automatically.

A1.72  Software routines should be incorporated which check the integrity of standard arithmetic operations.

Verification and validation

A1.73  The V&V team (independently from the designers) should verify that each stage of the software lifecycle is complete and correctly implements the requirements of the previous stage, in particular at the following stages:

  1. Requirements specification,
  2. Software and hardware specification,
  3. Software and hardware design,
  4. Software production and hardware manufacture,
  5. Software and hardware off-site test,
  6. Software and hardware on-site test,

A1.74  All verification and validation activities should be comprehensively documented to enable auditing.  Only deficiencies should be indicated by the V&V team; they should not recommend design changes. The extent of V&V coverage should be declared and justified.

A1.75  As part of the validation process the software submitted by the supplier should be subjected to independent assessment using an acceptable Static Analysis method. An example of such a method is MALPAS.

A1.76  As a precaution against the introduction of erroneous or unwanted code, the machine code of the system should be translated into a form suitable for comparison with the specification (reverse engineering). Any errors should then be corrected. This process can be carried out either manually or using software aids. For example, the system machine code might be dissassembled using a software tool and the resulting code translated into, say MALPAS Intermediate Language (IL). This IL could then be compared with the IL generated from the source code by using the Compliance Analysis feature of MALPAS.

A1.77  The V&V team should check that the software standards have been correctly implemented and that as far as possible errors have not been introduced. In particular they should check for:

  1. A complete, unambiguous and correct requirements specification,
  2. Correct implementation of all software modules,
  3. Timing and data errors,
  4. Good software structure,
  5. Adequacy of commenting and documentation,
  6. Appropriate use of fault tolerant and defensive programming features,
  7. Adequacy of software Failure Modes and Effects Analysis or Fault Tree Analysis,
  8. Adequacy of testing both off and on site,
  9. Deadlocks,
  10. Qualification of supporting software,
  11. Correct and complete implementation of modifications,
  12. Consistency throughout the whole lifecycle.


A1.78  The software should be qualified by an agreed comprehensive test programme which should encompass all modes of operation (particularly maximum loadings) and ranges of variables under conditions which are as representative of the operating environment as possible. This will require a range of diverse tests conducted both off-site and on-site.

A1.79  Testing should be conducted in a disciplined and orderly manner from module testing, through progressive integration and testing, to fully integrated system testing. During testing, the status of all outputs should be monitored to ensure that unintentional changes do not occur.

A1.80  Software should be tested by an independent team who independently devise and carry out the tests, and have no unrecorded verbal contact with the designers or implementors. Any errors should be documented and their correction tracked.  Errors should be analysed for cause and lack of early detection.

A1.81  Modification to existing software to correct errors or change functionality could potentially introduce errors. Such changes will necessitate requalification (known as regression testing). The degree of retesting will depend upon the amount of change that has taken place, its complexity and the complexity of the system. As a guide, for a non-trivial change, all modified modules and their interfaces to other modules should be subjected to repeat tests. Any deviation from full path coverage of a module and interface should be justified on the grounds of non-interaction.

A1.82  Protection systems should be subjected to a wide range of tests. Methods such as random and back-to-back testing are powerful techniques for revealing many types of error.

A1.83  The proposed tests should exercise the software across the full range of the requirements specification paying particular attention to boundary conditions. Also, by inspecting the code, tests should be devised which seek to detect such errors as stack overflow, divide by zero, numerical overflow, timing conflicts including bus contention problems etc.

A1.84  Consideration should be given to cliff edge effects to ensure that the system does not generate unsafe conditions when taken marginally beyond the specification limits. Adequacy of spare CPU time, scan times and data transfer rates should be demonstrated.

A1.85  Off-site test coverage should be such that all lines of code and (at system integration) all module calls are exercised at least once; this to be confirmed by coverage analysis. Operations on data items should be exercised at least once unless a bounding case can be made. All time critical sections of code should be tested at least once under realistic conditions. Where calculations are performed in the software their result should be checked against pre-calculated values. The fault tolerance of the system should also be tested by subjecting the system to appropriate tests, including those that are only implied by the specification.

A1.86  Once installed a test program should exercise cyclically all aspects of the hardware (including inputs and outputs), over an extended period of time (typically 400 hours) to establish that the hardware is sufficiently reliable to commence plant commissioning.

A1.87  On-site testing of the full system (software and hardware)  over an extended period (the duration will depend on system complexity, for example 12 months for a reactor protection system) will be required before active commissioning is permitted.  Actual plant inputs should be used as far as possible; the validity of simulated inputs should be justified and tests should demonstrate the correct operation of simulated items. Test coverage analysis should be provided. The reliability of the software together with a confidence estimate should be computed during the on-site tests, although the value obtained should not be interpreted as a measurement of in service reliability since however well prepared the test input combinations will not represent in scope or distribution the in service combinations. This probabilistic software reliability value should be compared with that obtained by judgement in the application of deterministic development methods (see A3.4) and if not smaller in terms of failures per demand than the judged value, then it must be taken that the applied methods have failed to be effective. In such a case the judged value should be revised in the light of actual performance.


A1.88  Documentation, in English, covering all aspects of the computer based protection system should be readily available (taking into account the need). It should reflect the as-built state, i.e. be correct, up-to-date and under a documentation management regime.

A1.89  The procedure for writing and quality control of all software should be set out in accordance with the quality assurance  arrangements.

A1.90  Programs should be well commented with information on the basic program function in the header and more detailed comments for program specialists in the body of the listing.

A1.91  Sufficient documentation should be available so as to provide a complete audit trail for all stages of the system life cycle from conception to termination of use. All decisions should be documented. Documents should be signed-off as checked and approved by authorised personnel. Modifications should be signed-off and include date, details of change and reason for change.

A1.92  Sufficient documentation should be available to enable suitably qualified staff to understand and maintain the system. The following documents should be available as a minimum:

  1. Operators' Manual - details facilities and use of the system in a non-technical language. Normal and abnormal operation should be described.
  2. Systems Description Manual - details in full the functions of the different parts of the system and the facilities offered to the operator and maintainer.
  3. Standard Hardware Documents - handbooks, instruction manuals and drawings for all bought-in items.
  4. Special Hardware Documents - full circuit diagrams, complete with component layouts and indications of normal signal levels plus a full parts list. Design principles, circuit operation, test procedures and fault diagnosis information should also be included.
  5. System Hardware Documentation - details of equipment arrangement, first line fault diagnosis information including the use of any test procedures and module replacement procedures.
  6. Standard Software - all software documentation for bought-in software such as
    compilers, linkers, utilities etc.
  7. Systems and Applications Software - details of the operation of the software system and individual programs should be given.  The content should be such that system maintainers can readily gain an appreciation of the overall system and individual programs. Descriptions of all functions, major task and programs together with their interrelationships.  The following data should be provided with each program module as a minimum:
    1. Purpose of module,
    2. System linkage,
    3. Initialisation,
    4. Data and parameter input,
    5. Data and parameter output,
    6. Data and files accessed,
    7. Data and files modified,
    8. Timing,
    9. Interrupts,
    10. Hardware interfaces,
    11. Program structure,
    12. Functional description of the program,
    13. Error returns,
    14. Size of module,
    15. Any special considerations.
  8. Detailed memory maps showing disposition of programs, data areas and spare memory.
  9. Data areas:
    1. Details of purpose,
    2. Format, 
    3. Type,
    4. Cross-references to programs using data,
    5. size of file/array.
  10. Listings - a complete listing of the source code fully commented.
  11. A complete memory dump.
  12. Control and data flow should be illustrated either in graphical or pseudo-code form for the overall system and for individual modules.
  13. Software and hardware part numbers and versions in use.
  14. Test results.
  15. QA Plan Compliance Record.
  16. List of software and hardware design standards.
  17. FMEA/FTA for hardware and software.
  18. V&V results.


A1.93  All staff associated with the operation of the system should have received adequate training in their particular role and be able to demonstrate competence prior to being permitted access to the system.


A1.94  Formal procedures should be in place for the documenting and timely reporting of residual software errors during the operational stage. The safety implications of such errors should be reviewed by appropriately authorised personnel.

A1.95  The system and procedures should be arranged so that only an approved program as a whole can be loaded into the system.

A1.96  Suitable arrangements should be made for the secure storage of copies of the software that is to be loaded in the event of a system failure. Due regard should be given to all possible means of corruption of the software. Particular attention should be paid to the secure storage of pre-programmed memory devices if they are used. Means should be provided to verify that the software has not been corrupted prior to its use both before and after loading. Automatic means are preferred.

A1.97  All necessary hardware and software for maintenance of the system should be in place prior to active commissioning.

Modification and maintenance

A1.98  No program modifications should be necessary as part of system operation and no facilities should be provided for this purpose. Protection system software should not be altered to overcome operational or maintenance difficulties, other than on an off-line system using agreed modification procedures. Engineered facilities should be provided where there is a need to change specific system parameters such as trip settings, calibration constants etc. for operational reasons. The available range should be limited to values supported by the safety case. A display of current values or states of such parameters should be provided.

A1.99  Modified software should be tested on a computer system identical to the installed system.

A1.100  Histories of all hardware modules should be maintained so that reliability claims can be monitored. Certificates of conformance should be available and a policy for faulty hardware modules of "repair and return" or "new for old" should be employed so that operating histories can be maintained, traced and properly interpreted.

A1.101  The repair and modification of both hardware and software should only be undertaken off-line. Such repair and modification should only be performed by personnel with proven competence in the relevant field and knowledge of that part of the system.

A1.102  Mean Time To Repair (MTTR) has an effect on total system reliability, therefore, there should be sufficient spares and test equipment, and adequately trained staff to enable the proposed figure to be met. The maximum on-line repair time allowed before the reactor or process must be shutdown should be stated and justified.

A1.103  Modifications arising at any time should be subjected to a full V&V process with test coverage analysis.