ГОСТ Р МЭК 61513—2011
- спецификацию сервисных функций и функций системного программного обеспечения.
П р и м е ч а н и е 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)Для функций категории А резервированная обработка не должна выполняться ресурсами той же
подсистемы, а резервированные сигналы — направляться по одному и тому же маршруту передачи дан
ных.
0 Функции категории А должны отвечать критерию единичного отказа как при работе, так и вслучае,
когда одна из резервированных линий защиты заблокирована для проведения операций обслуживания.
6.1.3 Детальное проектирование и реализация системы
Цель данной фазы жизненного цикла безопасности системы состоит в.
- разработке/получении подробного проекта оборудования системы.
- разработке (проектировании и программировании)/получении компьютерных программ, которые со
ставляют операционное и инструментальное программное обеспечение системы.
П р и м е ч а н и е 1— Нормально (см. 6.1.2.2), если выполняются только ограниченное количество новых
разработок, например, интерфейсов с другими системами;
- разработке (проектировании и программировании)/генерировании прикладного программногообес
печения системы.
39