ГОСТ Р МЭК 61513— 2011
П р и м е ч а н и е 2 — Если используется существующее оборудование, то прикладные программы генери
руются автоматически теми средствами, которые входят в спецификацию прикладного программного обеспече
ния (см. 6.1.2.3).
Документация по спецификации системы и план интеграции являются основными исходными данны
ми для фазы детального проектирования и реализации системы.
Результатами данной фазы являются:
- подсистемы и компоненты оборудования и программного обеспечения для последующей фазы
интеграциисистемы:
- компьютерные программы для работы в системе.
Разработка/приобретение оборудования и программного обеспечения являются частью их жизнен
ных циклов и в настоящем стандарте не рассматриваются.
Для систем класса 1требования к разработке программного обеспечения установлены в МЭК 60880
и МЭК 60880-2. а требования к оборудованию — МЭК 60987.
6.1.3.1 Анализ
6.1.3.1.1 Функциональная валидация спецификации требований кприкладным функциям
Функциональную валидацию проводят с целью выявления ошибок и пропусков в описании приклад
ных функций, которые могут быть не обнаружены при валидации системы (см. 6.1.5). Функциональная
валидация включает в себя моделирование работы АС и оборудования:
a)Для функций категории А должна быть проверена правильность спецификации прикладных функ
ций в сравнении с функциональными и характеристическими требованиями функций АС (см. 5.1.1).
b
)Для валидации должны использоваться окончательная версия прикладного программного обеспе
чения. созданного при детальном проектировании, и соответствующее аппаратное обеспечение.
6.1.3.1.20ценка надежности
a) Следует установить, что надежность прикладных функций, выполняемых системой, достаточна.
Строгость приводимых обоснований должна быть выше в случае функций высшей категории:
- обоснованиедолжно основываться на разумном сочетаниидетерминистических критериев и коли
чественного анализа надежности;
-оценивание влияния возможных отказов оборудования на надежность выполнения функциидолжно
проводиться с помощью вероятностного количественного анализа, основанного на интенсивности отказов
компонентов. Анализ охватывает архитектуру системы и компонентов и должен учитывать каксистемати
ческие. так и случайные отказы;
- оценивание влияния возможных ошибок при проектировании программного обеспечения на надеж
ность функций должно основываться на качественном анализе, принимая во внимание сложность проекта,
качество разработки, и учитывать опыт эксплуатации подобных объектов. Оценка, основанная на ранее
согласованных методиках, должна продемонстрировать то. что качество программного обеспечения соот
ветствует необходимой надежности.
П р и м е ч а н и е — Результаты анализа и имитационных испытаний могли бы быть использованы для
количественной оценки, но такой методики несуществует. Системы жесткой логики обычно не имеют количествен
ной оценки отказов, возникающих из-за ошибок при проектировании.
b
) Анализ возможности нежелательного воздействия сервисных функций системы на прикладные
функции следует провести с тщательностью, соответствующей важности прикладных функций для безо
пасности.
c) Если выполняемая системой функция входит в состав комплекса безопасности и существуют
требования кнадежности, предъявляемые структурой контроля и управления кэтому комплексу (см. 5.3.3.1),
то анализ надежности следует проводить с учетом последствий единичных отказов, отказов по общей
причине и развития отказов для всех систем, входящих вданный комплекс безопасности.
d) Для систем класса 1при анализе надежности следует также оценивать соответствие оборудова
ния для испытаний системы требованиям 6.1.1.2.4.
6.1.4 Интеграция системы
Цель данной фазы — соединение узлов оборудования и модулей программногообеспечения и про верка
совместимости загруженного в оборудование программного обеспечения (см. раздел 7 МЭК 60880).
Подсистемы и компоненты системы, детальная документация по разработке, план интегрирования
системы являются составными частями фазы интеграции системы.
40