Примечание - Интервалы замены оборудования могут определяться фактором ускоренного старения;
c) если операции по обслуживанию включают в себя адаптацию конфигурации или калибровочных данных, их следует контролировать при помощи документирования, которое позволит обеспечить:
- выполнение регулировок в установленных пределах (такие пределы могут устанавливаться проектами системы или энергоблока, тогда нет необходимости накладывать ограничения на действия обслуживающего персонала),
- если такие регулировки выполняются, когда система находится в работе, применяют требования 5.4.4,
- записи обо всех выполненных регулировках должны сохраняться.
5.5 Выходная документация
Выходная документация по проекту архитектуры контроля и управления и распределению функций является источником необходимых исходных данных для спецификации технических требований на отдельные системы из архитектуры контроля и управления (см. 6.1.1).
5.5.1 Документация по проекту архитектуры
a) Выходная документация должна определять для каждой системы контроля и управления:
- ограничения на проект, возникшие из-за особенностей АС (см. 5.1.3);
- ограничения, связанные с проектом архитектуры (см. 5.3.1);
- физическое и функциональное разграничения между системами.
b) Документация на используемый инжиниринговый инструментарий должна содержать информацию, из которой должно быть видно:
- каким образом проектирование как фаза жизненного цикла системы опирается на данные инструментальные средства;
- как должно использоваться каждое инструментальное средство;
- как должна верифицироваться выходная информация каждого инструментального средства.
Примечание - Требования к инжиниринговым методам и инструментальным средствам создания программного обеспечения для систем класса 1 приведены в 4.2 и 4.3 МЭК 60880-2.
5.5.2 Документация по распределению функций
a) Выходная документация должна определять функциональные требования, требования к характеристикам и надежности выполнения прикладных функций (см. 5.3.2), назначенных каждой системе. Требования могут быть оформлены в виде текстовой документации, блок-схем, матриц, структурных схем и пр., обеспечивающих ясное представление о функциях.
b) Спецификация требований к прикладным функциям компьютерных систем не должна зависеть от характеристик применяемой технологии, т.е. от компьютеров, реле.
c) Для разработки документов с требованиями, которые легко воспринимались бы как разработчиками технических требований к системе, так и операторами АС, должны использоваться инжиниринговые методы и инструментальные средства разработки систем и программного обеспечения.
6 Жизненный цикл безопасности системы
В проекте архитектуры контроля и управления выделяют отдельные системы контроля и управления, которые выполняют функции, важные для безопасности (см. 5.3.1). Настоящий раздел устанавливает цели систем и требования к таким системам. Требования раздела относятся также к компьютерным системам.
Примечание - Большая часть требований может применяться и к системам контроля и управления, выполненным по традиционным технологиям.
Для того, чтобы быть уверенным в том, что все связанные с безопасностью требования, которым должна соответствовать система, учтены, удовлетворены и реализованы, необходимо выполнять работу на основе системного подхода. Системный подход достигается за счет организации деятельности, связанной с разработкой, построением и эксплуатацией системы в рамках жизненного цикла безопасности системы. Этот жизненный цикл, в свою очередь, охватывается деятельностью, осуществляемой в рамках общего жизненного цикла безопасности контроля и управления (см. раздел 5 и рисунок 4).
Фазы типичного жизненного цикла безопасности системы включают в себя:
- спецификацию требований к системе;
- спецификацию на систему;
- детальное проектирование и реализацию системы;
- интеграцию системы;
- валидацию системы;
- внедрение системы;
- модификацию проекта системы (при необходимости).
Квалификацию системы рассматривают отдельно, поскольку ее можно выполнить частично вне рамок жизненного цикла безопасности системы. Этот подход учитывает имеющийся опыт, который все больше основывается на применении уже существующего оборудования.
Типичный жизненный цикл безопасности системы и связи с жизненными циклами программного обеспечения и оборудования в соответствии с требованиями МЭК 60880 и МЭК 60987 приведены на рисунке 5.
Рисунок 5 - Жизненный цикл безопасности системы
 | |
| 620 × 803 пикс. Открыть в новом окне | |
Примечание 1 - Для систем класса 1 требования к программному обеспечению на данной стадии определены в МЭК 60880.
Примечание 2 - Для систем класса 1 требования к оборудованию на данной стадии определены в МЭК 60987.
Примечание 3 - Для систем класса 1 требования к существующему программному обеспечению на данной стадии определены в МЭК 60880-2.
Рисунок 5 - Жизненный цикл безопасности системы
Обзор целей, исходных данных и результатов деятельности на различных фазах типичного жизненного цикла системы и ссылки на соответствующие подразделы приведены в таблице 3.
Таблица 3 - Обзор жизненного цикла безопасности системы
Раздел или подраздел | Исходные данные | Цель деятельности | Результат деятельности |
6 Требования к жизненному циклу системы и его связь с полным жизненным циклом безопасности | |||
6.1.1 Спецификация требований к системе | Результаты по 5.5; 5.4 | Разработка спецификации требований к: - функциям; - проектным ограничениям; - разграничению и интерфейсам с другими системами и устройствами; - интерфейсам взаимодействия с человеком; - условиям окружающей среды | Спецификация требований к системе. Требования к прикладным функциям |
6.1.2 Спецификация системы | Результат по 6.1.1. Документация на существующее оборудование, которое может использоваться. Результаты по 6.2.1, 6.2.2 | Оценка пригодности существующего оборудования для применения в проекте системы. Разработка проекта архитектуры системы, реализующего спецификации требований к системе. Распределение прикладных функций по подсистемам | Документация на спецификацию системы (см. 6.3.2), включающая в себя: - перечень выбранного оборудования и соответствующий анализ; - архитектуру системы; - спецификацию программного обеспечения |
6.1.3 Проектирование и реализация системы | Результат по 6.1.2 | Расширение и уточнение проекта архитектуры. | Детальная проектная документация на систему (см. 6.3.3). |
Результат по 5.1.1 | Разработка аппаратного и программного обеспечения (системного и прикладного). | ||
Результат по 6.2.1, 6.2.2 | Проверка требований к прикладным функциям | Функциональная валидация и расчет надежности (см. 6.1.3.1). Оборудование и программное обеспечение подсистем и компонентов | |
6.1.4 Интеграция системы | Результат по 6.1.3 Результаты по 6.2.1, 6.2.2, 6.2.3 | Сборка отдельных компонентов аппаратного и программного обеспечения, образующих систему | Отчет об интеграции. Интегрированная система |
6.1.5 Валидация системы | Результаты по 6.1.2 и 6.1.4 Результаты по 6.2.1, 6.2.2, 6.2.4 | Валидация спецификации на систему | Отчет о валидации системы |
6.1.6 Внедрение системы | Результаты по 6.1.5 Результаты по 6.2.1, 6.2.2, 6.2.5 | Установка, монтаж и испытание системы | Отчет о внедрении. Установленная и испытанная на объекте система |
6.1.7 Модификации проекта системы | Решение о модификации (если требуется) Результаты по 6.2.1, 6.2.2, 6.2.7 | Выполнение корректировок, улучшений или переделок системы | Отчеты о внесении изменений в систему. Модифицированная система |
6.2 Планирование системы | Результаты по 5.4, 6.1 | Разработка плана верификации, плана внедрения, эксплуатации и планов обслуживания и защиты | Планы системы |
6.4 Квалификация системы | Результаты по 6.2.1, 6.2.2 | Разработка плана квалификации | Квалификационная документация |
Примечание - Сравнение приведенного в таблице определения фаз с предложенным МЭК 61508-2 см. в приложении D. | |||
Настоящий раздел включает в себя:
- требования, предъявляемые ко всем системам, важным для безопасности;
- требования, предъявляемые (в дополнение к предыдущим) к определенным классам систем или категориям функций. Специальные требования приведены в таблице 4.
Жизненный цикл системы является итеративным процессом; фаза может начинаться, прежде чем деятельность в рамках предыдущей фазы завершится; однако фазу можно считать законченной только если предыдущие фазы завершены, а результаты их выполнения соответствуют исходным данным.
Примечание - Эти требования отличаются от требований 6.1 МЭК 60880. Для программного обеспечения желательно, но в качестве необходимого требования не рассматривается, завершать каждую фазу разработки до начала следующей фазы, выполняемой в соответствии с указанными выше требованиями.