ГОСТ Р МЭК 61513— 2011
Рассматриваются только первые две группы, поскольку проекты программного обеспечения и обору
дования не входят в область применения настоящего стандарта (см. 6.1.3).
П р и м е ч а н и е 2 — Для систем класса 1 требования к документации на программное обеспечение
установлены в МЭК 60880, МЭК 60880-2. а требования кдокументации на оборудование — МЭК 60987.
6.3.3.1 Содержание
a) Документация проекта системы должна быть полной, представлять всю информацию, необходи
мую для дальнейшей деятельности по обеспечению жизненного цикла безопасности системы, включая
интеграцию, валидацию, внедрение, эксплуатацию и обслуживание.
b
)Документация проекта системы развиваетсодержаниедокументации спецификации и должна пред
ставлятьдетальное описание внутренней структуры и внутреннего поведения системы. Уровеньдетализа
ции описания может быть соотнесен с классом безопасности системы.
c) Документация проекта системы должна включать в себя описание внедрения оборудования на АС
и проведения испытаний.
d) Документация проекта системы должна включать в себя описание функциональности и рабочих
характеристиксистемы, которыедолжны подвергаться валидации, в частности, ожидаемое время отклика
при различных условиях наАС. номинальная настройка уставок и алгоритмы управления, а также диапа
зоны безопасного регулирования.
6.3.3.2 Характерные черты проектнойдокументации
Характерные черты проектной документации на систему:
a) документация должна быть ясной и четкой, так чтобы каждая часть была однозначно понятной
заинтересованным специалистам, включая разработчиков и рецензентов плана интеграции, плана квали
фикации системы, плана внедрения и приемки и плана обслуживания системы, обслуживающему персо
налу, разработчикам и рецензентам модификаций проекта.
b
)должно быть обеспечено внесение изменений в документацию детального проекта системы втече
ние его разработки, чтобы гарантировать возможность применения окончательной версии документации
для реализации системы.
6.3.3.3 Верификация
a) Верификация детального проекта системы и его документациидолжна проводитьсядо реализации
нового оборудования и программного обеспечения; должно быть предусмотрено время для внесения по
правок. необходимость которых выявлена при верификации.
b
) Требования к надежности прикладных функций системы (см. 6.1.3.1.1)должны верифицироваться
на возможность их выполнения на ранней стадии детального проекта.
Примечание — Анализ надежности системы может потребовать внесения поправок вдетальный проект,
архитектуру системы, например, изменить степень резервирования и даже решения по выбору полной архитекту ры
контроля и управления.
c) Основываясь на оценке влияния прикладных функций на безопасность, следует провести строгий
анализ возможности их искажения при выполнении сервисных функций.
d) Допущения, внесенные при верификации детального проекта, должны быть сформулированы и
представлены в виде документа.
6.3.4 Документация по интеграции системы
6.3.4.1 Содержание
Документация по интеграции системыдолжна включать всебя план интеграции, отчет о проведенных
при интеграции испытаниях и всю информацию, необходимую для последующей фазы валидации.
6.3.4.2 Характерные черты
a) Отчет о проведенных при интеграции испытаниях должен содержать:
- варианты модулей оборудования и программ, спецификацию проведенных испытаний, использо
ванные инструментальные средства и оборудование, а также любые данные, относящиеся к калибровке;
- результаты каждого испытания с перечнем всех несоответствий между ожидаемым и действитель
ным результатами, и для каждого несоответствия — описание проведенного анализа и принятых решений
о продолжении испытания либо о внесении изменения.
b
) Для систем класса 1 применяют требования 7.7 МЭК60880.
48