ГОСТРМЭК 61511-2—2011
Чтобы обеспечить возможность обслуживания ПО на всем жизненном цикле ПСБ. необходимо
рассмотреть:
- программу управления изменениями (см. МЭК 61511-1. раздел 17);
- постоянную поддержку управления и обучение обслуживающего персонала.
- наличие средств поддержки и разработки на всем жизненном цикле ПСБ;
- наличие хорошо документально оформленных и. желательно, широко используемых методов
помощи соответствующим возможностям и навыкам человека на протяжении всего жизненного цик ла
ПСБ;
- использование правил проведения разработки и документального оформления, направленных
на облегчение понимания и ограничение влияния изменений в ПО;
- использование «встроенной» и обновляемой документации;
- способность к развитию и проверке в ходе функционирования.
12.1.2.5 Дополнительные требования не предусмотрены.
12.1.2.6 Дополнительные требования не предусмотрены.
12.1.2.7 Дополнительные требования не предусмотрены.
12.1.2.8 Дополнительные требования не предусмотрены.
12.2 Спецификация требований к безопасности ППО
12.2.1 Цель
12.2.1.1 Дополнительные требования не предусмотрены.
12.2.2 Требования
Общая структура ПСБ может налагать дополнительные функциональные требования на ПО кон
кретных функций безопасности ПСБ. Типичными примерами этого являются логика выбора «1 из2» для
резервных датчиков, а также установленные безопасные действия по обнаружению опасных отказов с
помощью самодиагностикидатчика. В примерах, приведенных в приложении В. перечислены такие тре
бования. порожденные применяемой архитектурой.
ППО должно также учитыватьдиагностические операции, реализуемые ПЭС иразработанные для
выполнения соответствующих действий, установленных в инструкции по безопасности логического
устройства.
Подробные требования по безопасности, предъявляемые к каждой функции безопасности ПСБ.
устанавливаютсяобычнос помощью логическихдиаграмм или причинно-следственныхсхем. Во многих
случаях для определения требований могут быть использованы языки программирования, предлагае
мые поставщиком логического устройства. Обычно используют языки функциональных блок-схем или
язык матриц причин и следствий. Поставляемый выбранный язык должен подходить для конкретного
применения. При определении подробных требований использование языков, предлагаемых постав
щиком. часто можетуберечь от ошибок, которые встречаются при переносе требований из других видов
документации. Для того чтобы определить функции безопасности и функции, не связанные с безопас
ностью. а также требования к УПБ всех функций безопасности, следует широко использовать коммента
рии.
Все функции, необходимые для всех режимов работы защищаемого процесса, должна охваты
вать подробная спецификация требований к функциональной безопасности. Кроме того, следует обес
печить периодическое проведение проверок всех функций безопасности ПСБ. Обычно это требует
определения дополнительных возможностей технического обслуживания, чтобы датчики и исполни
тельные элементы могли проверяться без останова процесса. Для документального оформления таких
требований может быть использована методология, описанная в предыдущем подразделе.
Если для выполненияфункций безопасности используется несколько ПСБ. то вдокументациисле
дует предусмотреть объяснение, какие функции выполняются каждой ПСБ. Если несколько ПСБ ис
пользуются для реализации одной и той же функции безопасности, то в документации следует указать
взаимодействие и независимость каждой ПСБ. Документация должна содержать сведения об ожидае
мом УПБ, который должен быть обеспечен для каждой ПСБ.
Дополнительные указания см. в 10.2.1 и 10.3.1.
12.2.2.1 Дополнительные требования не предусмотрены.
12.2.2.2 До разработки ППО пользователь обеспечивает проведение оценки опасности и риска
процесса, которое используется для установления требований к безопасности ПО в терминах функций
безопасности ПСБ иих УПБ. После того как принято решение о программной реализации функции безо
пасности ПСБ, по любым привлекшим внимание конфликтам, разногласиям и упущениям в специфика-
30