Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
I&C Safety Guide DRAFT 20110803.doc
Скачиваний:
13
Добавлен:
01.02.2015
Размер:
720.38 Кб
Скачать
  1. Confirmation of correct system behaviour following power interruptions and restart or reboot.

  2. Verification that the effects of automatic control system failures will not exceed the acceptance criteria established for anticipated operational occurrences.

6.32. Each assumption of an analysis should be stated, and justified in that analysis.

6.33. The methodology for any analysis conducted should be thoroughly defined and documented together with analysis inputs, results, and the analysis itself.

6.34. The analyses recommend by paragraph 6.31 are part of the plant safety assessment as described by NS-G-1.2, Ref. [10]. NS-G-1.2, Ref. [10] provides additional guidance on safety assessment.

6.35. Reliability claims for any I&C system that is based upon a common platform, regardless of technology, should be limited to 10-5/demand, regardless of the extent of to which the strategies described in Chapter 6 (e.g., redundancy) are employed.

6.36. Reliability claims for any individual I&C system that is based upon a common computer based platform, should be limited to 10-4/demand, regardless of the extent of to which the strategies described in Chapter 7 (e.g., redundancy) are employed.

System requirements

6.37. Requirement Engineering is an important factor for safety properties of digital I&C systems that are important to safety.

6.38. Requirement Engineering should allow developers to manage system requirements throughout the product life cycle to ensure that all requirements are implemented, checked and tested.

6.39. A System Requirements Specification should define what the I&C system must do, and must not do, within the context of the entire application.

6.40. The origin of and rationale for every requirement should be defined, to facilitate verification, traceability to higher level documents and a demonstration that all relevant design basis requirements have been accounted for.

6.41. Requirements essential to the functions important to safety should be distinct from all other requirements. Requirements that are not important to safety should be shown not to affect the functions important to safety (see paragraph 6.59).

6.42. The System Requirements Specification should explicitly define all relations between inputs and outputs for each of the operating modes.

6.43. Requirements should be described in terms understandable to all parties concerned (e.g.; the licensee, suppliers, and designers).

Hazards analysis

6.44. Hazards analyses should be performed for the I&C systems and the overall I&C architecture and the functionality within them to identify all potential system hazards that might compromise the I&C systems' safety functions.

6.45. These system hazards should be translated into system requirements that will serve to minimize, eliminate, or mitigate the effects of such hazards.

6.46. As the I&C progresses system’s interaction with the plant should be re-evaluated as part of the plant safety assessment detect and correct features of the detailed implementation that conflict with the goal of meeting the requirements for management of safety, the principal technical requirements, and the requirements of SSR 2/1. Ref. [1]. See NS-G-1.2, Ref. [10].

6.47. New or modified requirements or design features should be developed to deal with new contributions to hazards that are identified by the on-going hazard analysis.

I&C system validation planning

6.48. Validation should cover all requirements and specify the expected results for each test.

6.49. Items to be demonstrated by validation include, for example, the of full ranges (including out-of-range values for interface signals), exceptions handling, timing related requirements, set-point accuracies and hysteresis, demonstration that the system responds safely to all possible interface and load conditions, and coverage of all modes of operation of the system, including transition between modes and recovery after power failure.

6.50. The system validation plan should have provisions to test all parts of the system using realistic scenarios involving all inputs (dynamic testing).

6.51. The dynamic tests should be based on an analysis of the possible plant scenarios.

6.52. The test profiles should be representative of the expected plant parameter variations that would place demands on the I&C system.

6.53. The number of tests executed should be sufficient to provide confidence in the system’s dependability.

I&C system design

6.54. The system requirements that are to be satisfied by the I&C system should be mapped to an appropriate combination of hardware, devices configured with HDL, and software (if present).

6.55. Hardware might include application specific integrated circuits. Software might include pre-existing software and firmware, such as the operating system, software to be developed and/or software to be produced by configuring pre-developed software.

6.56. Chapter 10 gives recommendations for refining the system requirements for software into software requirements.

6.57. The refined requirements might also have to account for lower level design decisions made for parts of the system outside the I&C system, e.g. the type and performance of actuated devices.

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