- независимости коммуникаций компьютерных систем, которая достигается выбором подходящих архитектур передачи данных и протоколов обмена (см. 5.3.1.3).
Примечание 1 - Требования по электрической изоляции и физическому разделению приведены в 4.3 МАГАТЭ 50-SG-D8 и 7.8 МАГАТЭ 50-SG-D3.
b) В системах класса 1 физическое разделение и электрическая изоляция между подсистемами различных групп безопасности должны соответствовать требованиям МЭК 60709.
c) Разделение и изоляция между системами класса 1 и системами и оборудованием, не влияющим на безопасность, должны соответствовать требованиям МЭК 60709.
Примечание 2 - Предпочтительным способом физического разделения и защиты кабелей систем безопасности (как электрических, так и оптических) является использование выделенных кабельных проходок или каналов, обеспечивающих полную защиту от опасных воздействий.
6.1.2.2.3 Защита от развития отказов и их побочных эффектов
Кроме развития отказов, которое можно предотвратить за счет обеспечения независимости, следует рассматривать другие типы развития последствий отказов в компьютерных системах, например:
- непреднамеренное прерывание разделяемых ресурсов (вычислительная мощность, полоса пропускания коммуникаций, память, ресурсы операционной системы и т.д.);
- отказ разблокировки прерванных ресурсов;
- разрушение синхронизации в пределах системы или в пределах архитектуры контроля и управления.
Кроме того, сбой в программе, который препятствует выполнению определенной функции, может привести к отказу других программ, обслуживающих другие функции этой же системы (побочные эффекты). Отказ может произойти вследствие ошибок в данных программах или оборудовании, используемом для выполнения различных функций, например, отказ процессора может привести к отказу других функций вследствие исключения или зависания одной из функций.
Архитектура системы должна минимизировать риск и последствия от развития отказа и побочных эффектов, связанных с отказами. Можно рассматривать следующие технологии:
- внутренняя изоляция, когда отказ не может развиться из-за отсутствия соответствующих путей развития и вследствие разделения ресурсов;
- система мониторинга с помощью внутренних (например, самодиагностика) или внешних (например, другие системы или операторы) средств системы, способных обеспечить раннее выявление искаженных данных и/или отказавших ресурсов;
- защитные интерфейсы, позволяющие системе или ее подсистемам выявлять искаженные входные данные и/или неправильные взаимодействия;
- встроенная валидация резервированных входных сигналов, используемых для последующей обработки;
- строго определенные режимы поведения, используемые для выявления отказа и позволяющие системе снизить вероятность развития отказа и/или его воздействие.
Примечание - Детальные требования, позволяющие избежать склонности программных комплексов к ошибкам, и требования к верификации и испытаниям программных модулей приведены в МЭК 60880 и МЭК 60880-2.
6.1.2.3 Спецификация программного обеспечения
Спецификация программного обеспечения включает в себя:
- спецификацию прикладных функций (характеристики прикладных программ);
- спецификацию архитектуры программного обеспечения.
Примечание 1 - Архитектура программного обеспечения определяет основные компоненты и программное обеспечение подсистем, их взаимосвязь и как требуемые свойства будут достигнуты. Требования к архитектуре программного обеспечения не входят в область применения настоящего стандарта (для систем класса 1 см. МЭК 60880 и МЭК 60880-2);
- спецификацию сервисных функций и функций системного программного обеспечения.
Примечание 2 - Если используется существующее оборудование, то спецификации системного программного обеспечения являются в основном частью документации на оборудование.
a) Для того, чтобы облегчить выполнение спецификации, верификацию и валидацию прикладных функций, архитектура программного обеспечения должна предусматривать четкое разделение между прикладным и системным программным обеспечением (см. В.2а МЭК 60880). В этом случае верификация и валидация прикладного программного обеспечения могут выполняться независимо.
b) Спецификация прикладного программного обеспечения должна основываться на спецификации требований к прикладным функциям (см. 6.1.1.1). При необходимости в нее следует включать связи с функциями контроля и мониторинга системы.
c) Для того, чтобы избежать ошибок при спецификации и верификации, программное обеспечение каждой прикладной функции должно быть по возможности уточнено за счет введения в структуру компонентов со стандартными рабочими характеристиками.
Примечание 3 - Существует покупное оборудование, которое может включать в себя описание разработанного прикладного программного обеспечения с соответствующими средствами, использующими подходящие существующие компоненты библиотеки прикладных программ.
d) Для того, чтобы реализовать поддерживающие режимы работы и свести к минимуму вероятность ошибочных действий, должны быть описаны соответствующие средства отбора и верификации сигналов, а также блокировки.
6.1.2.4 Распределение прикладных функций в системе
Рассматривается распределение:
- входных сигналов запуска или окончания функций по определенным процессорным устройствам;
- процедур голосования, управления по приоритетам, функций защиты оборудования;
- связей выходных управляющих действий с исполнительными устройствами.
a) Распределение функций, важных для безопасности, по системам и подсистемам должно соответствовать спецификациям функциональных требований, требований к рабочим характеристикам и к категоризации функций (см. 6.1.1.1.1).
b) При распределении следует учитывать содержание отказов.
c) Резервированные функции и сигналы, важные для безопасности, не должны обрабатываться в одной и той же подсистеме, чтобы при отказе или при случаях локальных опасных воздействий, возникших в одном канале, система могла бы выполнять свои функции.
d) Функции различных категорий, приданные одной системе или подсистеме, должны рассматриваться как функции наивысшей из их числа категории безопасности, исключая случаи, когда можно показать, что более низкая категория данных и функций не может нарушить работу функций более высокой категории. Это может привести к разделению функций в различных подсистемах или к решению о размещении функций более низкой категории в других системах [итерационный процесс при общем распределении (см. 5.3)].
e) Для функций категории А резервированная обработка не должна выполняться ресурсами той же подсистемы, а резервированные сигналы - направляться по одному и тому же маршруту передачи данных.
f) Функции категории А должны отвечать критерию единичного отказа как при работе, так и в случае, когда одна из резервированных линий защиты заблокирована для проведения операций обслуживания.
6.1.3 Детальное проектирование и реализация системы
Цель данной фазы жизненного цикла безопасности системы состоит в:
- разработке/получении подробного проекта оборудования системы;
- разработке (проектировании и программировании)/получении компьютерных программ, которые составляют операционное и инструментальное программное обеспечение системы.
Примечание 1 - Нормально (см. 6.1.2.2), если выполняются только ограниченное количество новых разработок, например, интерфейсов с другими системами;
- разработке (проектировании и программировании/генерировании прикладного программного обеспечения системы.
Примечание 2 - Если используется существующее оборудование, то прикладные программы генерируются автоматически теми средствами, которые входят в спецификацию прикладного программного обеспечения (см. 6.1.2.3).
Документация по спецификации системы и план интеграции являются основными исходными данными для фазы детального проектирования и реализации системы.
Результатами данной фазы являются: