b) Архитектура и технология линий передачи данных должны обеспечивать соблюдение требований независимости систем. Кроме физического разделения и электрической изоляции в проекте должны быть предусмотрены меры, гарантирующие отсутствие влияния неполадок в системе передачи данных на работу средств обработки.
c) Линии передачи данных должны включать в себя средства проверки работоспособности коммуникационного оборудования и полноты передаваемых данных.
d) Для устойчивости к отказам должно быть обеспечено резервирование линий передачи данных.
е) Линии передачи данных должны быть спроектированы так, чтобы передача данных и выполнение функции более высокой категории безопасности не нарушались при передаче данных в системе более низкого класса. Например, выполнение тестов на работоспособность не должно мешать выполнению функции высшей категории.
5.3.1.4 Инструментальные средства
a) В проект архитектуры контроля и управления должны быть включены инструментальные средства, выполняемые обычно на базе компьютеров (см. 4.2 МЭК 60880-2), которые обеспечивали бы устойчивость обмена данными между системами контроля и управления, работающими совместно, и гарантировали бы сохранность базы данных АС.
Примечание - Специальные инструментальные средства для отдельных систем выбирают на стадии разработки спецификации системы (см. 6.1.3.2).
b) Инструментальные средства должны применяться на всех фазах полного жизненного цикла безопасности, за счет чего может быть достигнуто повышение качества и надежности функций, важных для безопасности, например, для поддержки:
- аспектов, связанных с проектом интерфейсов между системами контроля и управления;
- общей интеграции и приемки распределенных функций.
5.3.1.5 Защита от отказов по общей причине
Цель проекта архитектуры контроля и управления - обеспечить меры защиты от отказов по общей причине систем контроля и управления путем введения различных защитных мер против одних и тех же постулированных исходных событий (см. 5.1.1).
Эти меры защиты включают в себя:
- проектные решения по обеспечению устойчивости к опасным событиям на АС. Внешние и внутренние опасности (см. 5.1.3), влияние которых не исключено для ограниченной части архитектуры контроля и управления и которые могут привести к отказам по общей причине;
- проектные решения, направленные против отказов, которые могут быть вызваны изменениями в нагрузке АС. Включение некоторых компонентов оборудования, например, усилителей мощности и реле, или ввод компонентов программного обеспечения, например, таких как сбор входных данных, передача данных и переключение эксплуатационных режимов, могут зависеть от событий, происходящих на АС;
- проектные решения по минимизации использования общих ресурсов в архитектуре контроля и управления и взаимодействия человек - машина для различных уровней защиты. Такие общие ресурсы можно представить в виде использования одного сигнала измерения или обычной технологической операции в различных управляющих действиях;
- решения по минимизации риска систематических сбоев. В любой системе контроля и управления существует риск проектных ошибок или присутствуют ошибки, связанные с реализацией. Поэтому возможность сбоя программного обеспечения, вызывающего отказ, нельзя исключить при анализе любого отказа системы. Если используются одинаковые программные модули в сходных условиях в разных компьютерных системах, существует риск отказа по общей причине вследствие такой ошибки в программном обеспечении;
- использование разнообразия. Разнообразие обеспечивает несколько различных путей обнаружения значительных событий и реагирования на них для увеличения защиты от отказа по общей причине. К видам разнообразия относятся разнообразие персонала, разнообразие сигналов (использование разных измерительных параметров для инициирования защитных действий), функциональное разнообразие, разнообразие проектных решений и проверок, разнообразие программного обеспечения и оборудования;
- принятие стратегических решений по ограничению сложности. Использование компьютеров способствует выполнению более сложных алгоритмов и процессов, чем это возможно с помощью оборудования с жесткой логикой. При более сложных требованиях возможность ошибок и просчетов в спецификации требований и ошибок в проекте и при реализации становится значительно больше, чем в случае простых требований.
5.3.1.5.1 Устойчивость к внутренним и внешним воздействиям, которые могут привести к отказу по общей причине
Необходимо принять меры, обеспечивающие работоспособность комплекса безопасности, выполняющего функции категории А, которые требуется поддерживать на случай противодействия внутренним и внешним опасным воздействиям.
Эти меры включают в себя:
- разделение, например, размещение резервных частей системы в различных помещениях;
- независимость, например, систем подогрева, вентиляции и кондиционирования воздуха и отдельных источников энергоснабжения для каналов и систем;
- защита, например, от огня, воздействия химических веществ и вибрации;
- проектирование, например, оборудования в соответствии со стандартами МЭК по электромагнитной совместимости;
- квалификацию по воздействиям окружающей среды, например, по отношению к сейсмическим воздействиям (см. 6.4).
5.3.1.5.2 Защита от отказов по общей причине вследствие изменения потребности в энергии
a) Необходимо определить выполняющие функции категории А компоненты систем контроля и управления, работа которых зависит от нагрузки станции. Возможные виды отказов и их последствия (включающие в себя их влияние на компоненты, работа которых не зависит от режима нагрузки станции) должны быть оценены с точки зрения вероятных источников и эффектов отказа по общей причине.
b) Риск отказов по общей причине систем класса 1 должен быть минимизирован за счет использования систем контроля и управления и обеспечивающих систем, которые работают в одном и том же режиме как до, в процессе, так и после изменения нагрузки, т.е. их работа не должна зависеть от графика приложения нагрузки.
5.3.1.5.3 Защита за счет проектных решений по архитектуре систем контроля и управления и человеко-машинному интерфейсу
a) Различные рубежи защиты против постулированных исходных событий должны быть оснащены независимыми системами или подсистемами (см. примечание 1 к 5.1.1). Если используются общие ресурсы, они должны соответствовать плану обеспечения надежности комплекса безопасности.
b) Должны быть предусмотрены независимые средства контроля и управления функциями и системами, важными для безопасности АС (например, мультиплексные линии передачи данных или компьютеры), чтобы во время отказа имелась достаточная информация, необходимая для безопасной эксплуатации АС.
c) Если управление функциями категории А или В выполняется вручную как дублирующее действия автоматики, то возможность отказа по общей причине в процессе этих действий должна быть сведена к минимуму.
d) Если одна функция категории А может инициировать действие системы безопасности, а другая функция категории А, применяемая при других обстоятельствах, может вызвать противоположное действие, необходимо провести анализ с целью определения того действия, которое требуется выполнить в условиях отказа систем контроля и управления.
5.3.1.5.4 Защита от отказа по общей причине вследствие систематических сбоев
a) Планирование высокого качества, предусмотренное при разработке и создании различных систем контроля и управления комплекса безопасности, должно исключать случаи невыявленных отказов и, таким образом, свести риск отказов этих систем по общей причине к минимуму. Настоящий стандарт содержит требования, которые следует применять для обеспечения качества систем контроля и управления различных классов.
b) Систематические отказы должны выявляться средствами самоконтроля (исключая использование ручек настройки, аппаратуры самоконтроля, проверок правдоподобия), а выявляемые отказы должны переводить систему(ы) в предварительно установленное, предпочтительно безотказное состояние, при этом оператор должен получать сообщение об отказе.
c) Если требуемая надежность безотказного выполнения функции безопасности больше, чем надежность, полученная в результате оценки безотказного состояния данной системы, то проект данной системы следует переработать.
Примечание 1 - Требуемая степень защиты от отказов зависит от категории выполняемых функций.
Примечание 2 - Цель настоящего подраздела - дать общие сведения. Детальные требования к защите от отказов по общей причине вследствие ошибок в программном обеспечении для функций категории А приведены в 4.1 МЭК 60880-2.
5.3.1.5.5 Защита за счет разнообразия
a) В случае, если требуется высокая надежность комплекса безопасности, при проектировании архитектуры контроля и управления следует опираться на принцип разнообразия, особенно если имеются неопределенности в выполненных в проекте оценках.
b) Необходимо рассмотреть методы функционального разнообразия и разнообразия сигнала. Эти методы являются эффективными для снижения вероятности отказа по общей причине, возникшего вследствие ошибок в спецификациях требований или в спецификации и установке прикладного программного обеспечения.
c) Разнообразие оборудования может быть эффективным против отказа по общей причине компонентов аппаратного обеспечения и может обеспечить защиту против сбоев программного обеспечения системы. В частности, ее следует рассматривать при создании сложных систем, если опыт эксплуатации подобных систем ограничен.
d) Следует использовать разнообразие процедур или методов верификации и валидации (например, разнообразие оборудования для электромагнитных испытаний, испытания на взаимную совместимость с использованием эмулятора и пр.), что дополнительно поможет избежать отказов по общей причине без усложнения системы защиты.
e) Если для защиты против отказа по общей причине используется защита за счет разнообразия, то в проект следует включить анализ ее эффективности. Как положительный, так и отрицательный результат следует зафиксировать и отразить в документации (см. 5.3.3).
5.3.1.5.6 Стратегические решения по ограничению сложности
Для того, чтобы снизить до минимума вероятность отказа по общей причине из-за сложности систем, проектирование архитектуры контроля и управления должно включать в себя анализ, показывающий, что степень применения компьютеров вместо систем, построенных на жесткой логике, и степень участия человека приемлемы с точки зрения обеспечения безопасности.
Примечание - Такой подход может зависеть от национального опыта, позиции регулирующего органа и надежности компьютерных технологий.