ГОСТ ISO 13849-1—2014
2)не должно быть логического объединения данных, связанных и не связанных с обеспечением
безопасности, что может привести к снижению полноты сигналов, связанных с безопасностью, напри
мер, объединение связанных и не связанных с безопасностью сигналов логическим «ИЛИ», когда ре
зультат управляет сигналами, связанными с обеспечением безопасности;
e) внедроние/кодирование программного обеспечения:
1) код должен быть четким, понятным и тестируемым, поэтому должны использоваться символь
ные переменные (вместо подробного описания адресов технических средств);
2) должны использоваться подтвержденные или принятые рекомендации по выполнению кодиро
вания;
3) должны применяться проверки целостности и достоверности данных (например, проверка по
падания в интервал), доступные на прикладном уровне (защитное программирование);
4) код должен быть проверен моделированием;
5) верификация должна проводиться посредством контроля и анализа потока данных для уровня
PL
= d
или е;
f) тестирование:
1) подходящим методом подтверждения является тестирование функционального поведения, а
также критериев эффективности (например, эффективность использования рабочего времени) мето
дом черного ящика:
2) для PL
- d
или
в
рекомендуется использование тестовых вариантов, полученных на основе
анализа граничных значений;
3) рекомендуется проводить планирование испытаний, причем планирование должно включать в
себя тестовые варианты с критериями завершения и требуемыми программными средствами;
4) тестирование входов/выходов должно гарантировать, что сигналы, связанные с безопасностью,
правильно использованы в рамках SRASW;
д) документирование:
1) весь жизненный цикл программного обеспечения, а также работы, связанные с модификацией,
должны быть снабжены документацией;
2) документация должна быть полной, доступной, четкой и ясной;
3) документация системы кодирования в пределах исходного текста должна содержать заголовки
модулей, указывающие на область применения, описание функциональных задач и входов/выходов,
информацию о версии системы кодирования и версии используемых функциональных блоков библио
тек, а также необходимые ссылки на интернет-ресурсы/официальные отчеты и строки-описания;
h) верификация1
Пример
—
Анализ, проверка, сквозной контроль или другие подходящие меры.
i) управление конфигурацией
Настоятельно рекомендуется ввести резервные копии данных и процедур с целью последующей
идентификации и архивирования документов, программных модулей, результатов верификации/вали-
дации. а также конфигурации программных средств, относящихся к особой версии SRASW:
j) модификации
После модификации SRASW должен быть проведен анализ воздействий с целью обеспечения
технических требований. Также после модификации должны быть проведены соответствующие рабо
ты. касающиеся жизненного цикла программного обеспечения. Права доступа к модификациям должны
находиться под контролем, история модификаций должна быть задокументирована.
Примечание — Модификации не затрагивают уже используемые системы.
4.6.4 Параметризация на основе программного обеспечения
Программная параметризация показателей, связанных с обеспечением безопасности, должна
рассматриваться в качестве аспекта безопасности конструкции SRP/CS, которые должны быть описа ны
в спецификации требований по безопасности программного обеспечения. Параметризация должна
проводиться при использовании предназначенных для этого программных средств, предусмотренных
поставщиком SRP/CS. Эти программные средства должны иметь свои параметры для идентификации
(название, номер версии и т. д.). а также предотвращать несанкционированные изменения, например, с
помощью защиты паролем.
1 Верификация необходима только для программы специального назначения, а не для утвержденных би
блиотечныхфункций.
20