ГОСТРМЭК 61511-2—2011
d) определение способов диатостики датчиков и исполнительных элементов, а также организации
периодических проверок. Они будут зависеть от резервирования датчиков и исполнительных элементов.
Организация проверок должна быть тщательно определена и предусматривать соответствующую аварий
ную сигнализацию в ходе проведения проверки;
e) определение коммуникационных переменных для других систем, внешних к ПСБ. Если эти пе
ременные размещаются в памяти, то они должны быть приписаны к соответствующим областям памяти
так. чтобы коммуникационная подсистема могла иметь к ним доступ. Переменные, которые могут изме
няться другими системами, внешними к ПСБ. должны быть аккуратно определены и. как правило, раз
мещены в специальной области памяти, предназначенной для чтения и записи;
f) определение того, где и как регистрируются последовательности событий, и понимание их вли
яния на ПСБ;
д) разработка заказных функций и функциональных блоков. Такая возможность применения за
казных функциональных компонентов весьма желательна, так как в прикладных программах могут быть
запрограммированы, испытаны и повторно использованы повторяющиеся операции.
П р и м е ч а н и е — Термины «функция», «функциональный блок» и «программа» определены в (12);
l
h) принятие решения о том. какие функциибезопасности ПСБ и другиефункции следует включить
вданную программу. Желательно разделитьфункции безопасности ифункции, не связанные с безопас
ностью, по разным программам так. чтобы основной акцент мог быть сделан на программах, критичных
для безопасности. Желательно также ограничить размер одной программы небольшим числом
функций;
i) составление прикладных программ. Структура прикладной программы должна соответствовать
структуре процесса (например, на химическом обьекте ППО для каждого участка процесса должно быть
сгруппировано вместе; внутри каждого участка процесса следует обеспечить распределение ПО между
оборудованием для облегчения понимания и обслуживания);
j) определение правильного порядка выполнения сетевых и логических операций внутри каждой
программы, а также последовательности и требуемойскорости выполнения всех прикладныхпрограмм.
Подтверждение того, что скорости выполнения прикладных программ согласованы с необходимыми
временами реакции процесса, приведенными в спецификации требований к безопасности ПО;
k) проверка ППО с использованием контролирующих возможностей среды разработки (если воз
можно);
) загрузка ППО в логическое устройство;
т ) проверка всех входов ивыходов логического устройства, ППО иинтерфейсовс другими систе
мами. внешними для ПСБ.
12.4.3.1 Дополнительные требования не предусмотрены.
12.4.3.2 Дополнительные требования не предусмотрены.
12.4.3.3 Дополнительные требования не предусмотрены.
12.4.3.4 Дополнительные требования не предусмотрены.
12.4.3.5 Примерами верификации полноты безопасности данных могут служить; -
проверка выхода входных/выходных данных за границы заданных диапазонов; -
подтверждение соответствия передаваемых прикладных данных;
- проверки согласованности наименований индексов (например, проверки многократного исполь
зования одного и того же имени индекса);
- проверки правильности прекращения обслуживания (например, при обслуживании и запуске);
- проверка правильности настроек и сигнализации.
12.4.4Требования к средствам поддержки, руководству пользователя и прикладным
языкам
Среда разработки представляетсобой совокупность инструментальных средств, которые поддер
живают процессы кодирования ППО. конфигурирования прикладных параметров и интерфейсов, а так же
проверки и контроля выполнения прикладных программ. Обычно такая среда включает в себя
следующие средства;
a) редактор конфигурации. Этот редактор используется, чтобы сконфигурировать подсистему
входое/выходов, входные/аыходные переменные памяти и функции коммуникации;
b
) языковые редакторы. Эти редакторы использует прикладной программист при разработке про
грамм. выполняющих все необходимые в данной системефункции (связанные или несвязанные сбезо
пасностью);
34