Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
I&C Safety Guide DRAFT 20110803.doc
Скачиваний:
13
Добавлен:
01.02.2015
Размер:
720.38 Кб
Скачать

10.49. Coding rules should be prescribed and adherence verified.

10.50. Data structures and naming conventions should be consistently applied.

10.51. The software implementation should be subject to defined procedures for change control, configuration management and ensuring full test coverage for the results of all changes (see paragraph 2.15).

10.52. Software self-supervision and self-checking requirements should be reviewed during software implementation and the design revised as necessary.

10.53. The programming language (or language subset) used should be adequate in terms of expressive power, avoidance of insecurities, level of abstraction, support for modularization and information hiding, compilation and run-time checking, and error handling.

10.54. For safety systems, the choice of programming language should be justified and documented.

10.55. For systems other than safety systems, the choice of all programming languages and/or functional definition methods (such as logic diagrams or graphical representations) used should be based on a systematic assessment of the functionality and integrity of the processes involved.

10.56. Assembly language should only be used for modules of limited size and functionality, and only if this is justified by real time performance or compatibility constraints.

10.57. The description of all languages used and of the functional definition methods should be precise and documented.

10.58. For safety systems, the language syntax and semantics should be complete, available, and rigorously defined.

10.59. Software functions used should be limited to the minimum necessary and should be identified, have well defined interfaces and always be called in accordance with the relevant restrictions in their use.

10.60. Software functions might be intrinsic to the programming language, contained in libraries or otherwise pre-developed.

10.61. Relevant and documented experience on the use of pre-existing functions (i.e., not written solely for the system under development) in an operating environment should be available.

10.62. If an operating system is used, it should be thoroughly and satisfactorily tested and its suitability for the target application should be justified.

10.63. For safety systems, any operating system software should comply with the full recommendations of this Safety Guide.

10.64. A suitable set of implementation tools should be selected with the aim of minimizing error. See paragraphs 8.152-8.168 for relevant recommendations.

10.65. The recommendations in this chapter apply to all possible combinations of the use of code generation and classical software development.

10.66. Software diversity, i.e., the use of independent development teams or methods, should be considered as a means of reducing the likelihood and effect of software common cause failures to the extent required by the overall design.

10.67. Precautions should be taken to ensure that the independence between systems supporting different levels of defence in depth is not jeopardized by the use of identical software, such as the operating system, network communication, or other running support software.

SOFTWARE VERIFICATION AND ANALYSIS

10.68. The software requirements, design and implementation should be verified against the plant safety criteria.

10.69. Verification of traceability should be an on-going activity to ensure shortfalls are addressed as early as possible and hence necessary changes remain practicable.

10.70. The results of each software life cycle phase should be verified against the requirements set by the previous phases (see paragraph 6.25).

10.71. A verification plan should be produced that documents the following:

  1. The verification techniques to be used;

  2. Details of or references to the procedures to be used in applying each technique, including its scope and depth;

  3. How non-functional requirements and constraints will be demonstrated to be met;

  4. Criteria for when sufficient verification has taken place, including targets for; completeness with respect to the outputs of the previous phase and for structural test coverage, and how these will be demonstrated;

  5. The means by which results will be recorded;

  6. The means by which non-compliances and faults will be recorded and resolved;

  7. The team or teams performing the verification;

  8. The functionality of any verification tool, including expectations and limitations on how it is to be used (e.g., domain, language, process); and

  9. Rationale for the above and justification that this is sufficient for software of the safety classification to which it is applied.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]