ГОСТ Р МЭК 61511-2—2011
12.4.2.3 Дополнительные требования не предусмотрены.
12.4.2.4 Вообще говоря, для того чтобы обеспечить проверяемость, рекомендуется, чтобы
спецификации испытаний интеграции ППО были рассмотрены еще в ходе стадий проектирования и
разработки.
12.4.2.5 Если ППО ПСБдолжно реализовывать функции безопасности ПСБ с различнымиУПБ. то
их следует четко разделить и промаркировать. Это позволит сделать ПО каждой функции безопасности
ПСБ прослеживаемым вплоть до каждого резервного датчика и каждого резервного исполнительного
элемента. Это даст также возможность выполнять функциональное испытание и подтверждение соот
ветствия функций в соответствии с УПБ. Маркировка должна идентифицироватьфункции безопасности
ПСБ и УПБ.
Для функций безопасности ПСБ и функций, не связанных с безопасностью, следует использовать
отдельные ПО. Одним из способов показать их адекватную независимость может быть выполнение
всех следующих позиций:
a) функции безопасности ПСБ понятно промаркированы в ППО как прикладные коды функции бе
зопасности ПСБ;
b
) функции ПСБ. не связанные с безопасностью, явно отделены в ППО;
c) все переменные, используемые при выполнении функций безопасности ПСБ. промарки
рованы;
d) все коды прикладных программ, реализующих функции ПСБ. не связанные с безопасностью,
промаркированы как коды функций, не относящихся к безопасности;
e) все коды прикладных программ, использующие переменные, не связанные с безопасностью, и
переменные функции безопасности ПСБ удовлетворяют следующим условиям;
- коды прикладных программ (программы, функции и функциональные блоки), не связанные с
безопасностью, не должны изменять переменные функции безопасности ПСБ. используемые в кодах
прикладных программ безопасности:
- коды прикладных программ безопасности, реализующихфункции безопасности ПСБ. недолжны
зависеть от любых переменных, не связанных с безопасностью;
f) все ППО (то есть коды и переменные) защищено от любых изменений ПО, не связанного с без
опасностью;
д) если безопасное ППО и ППО. не связанное с безопасностью, совместно используют одни и те
же ресурсы (например, центральное процессорное устройство (ЦПУ), ресурсы операционной системы,
память, шины], то функциябезопасности ПСБ (например, время реакции) безопасного ППОни при каких
обстоятельствах не должна оказаться под угрозой.
В идеальном случае взаимовлияние между кодами ППО (функций безопасности ПСБ и функций,
не связанных с безопасностью) и всеми переменными (функций безопасности ПСБ и функций, не свя
занных с безопасностью) должно автоматически проверяться с помощью разрабатываемого ППО. Если
эта возможность недоступна, то разработчики ППО и другие лица, выполняющие верификацию и
под тверждение соответствия ППО. должны проверять все прикладные коды и связанные с ними
перемен ные на соответствие приведенным выше правилам разделения.
12.4.2.6 Дополнительные требования не предусмотрены.
12.4.2.7 Дополнительные требования не предусмотрены.
12.4.3Требования к архитектуре ППО
Варианты архитектуры ППО в типовых логических решающих устройствах ПСБ достаточно огра
ничены и вполне понятны при рассмотрении основных действий при разработке прикладных программ.
Обычно разработчик при выполнении разработки и испытаний прикладных программ выполняет следу
ющие основные действия:
a) выбор конфигурации модулей ввода’вывода и области памяти для переменных данных;
b
) создание имен для всех входов/выходов изапоминаемых переменных. Наименованиядолжны
соответствовать соглашению непротиворечивости;
c) определение способа прекращения обслуживания. Некоторые пользователи будут требовать,
чтобы для прекращения обслуживания к цифровым входам были подсоединены переключатели. Другие
будут использовать управляемый вводданных в ПСБ из рабочей станции. В любом случаедолжно быть
обеспечено безопасное управление, предотвращающее непреднамеренное прекращение обслужива
ния. О прекращении обслуживания должно быть объявлено;
33