ГОСТРМЭК 62279—2016
Введение
Настоящий стандарт входит в группу связанных стандартов вместе с МЭК62278:2002 «Железные
дороги. Технические условия и демонстрация надежности, эксплуатационной готовности, ремонтопри
годности и безопасности» и МЭК 62425:2007 «Железные дороги. Системы связи, сигнализации и об
работки данных. Связанные с безопасностью электронные системы сигнализации».
МЭК 62278:2002 рассматривает проблемы крупных систем, а в МЭК 62425:2007 рассмотрен по
рядок утверждения отдельных систем, которые могут существовать внутри общей системы управления и
защиты на железнодорожном транспорте. Настоящий стандарт уделяет внимание практическим ме
тодам создания программного обеспечения, удовлетворяющего требованиям полноты безопасности,
которые определяются в результате анализа таких крупных систем.
Настоящий стандарт обеспечивает ряд требований, которым должны соответствовать разработ
ка. внедрение и обслуживание любого связанного с безопасностью программного обеспечения, пред
назначенного для приложений управления и защиты на железныхдорогах. Он определяет требования,
связанные с организационной структурой, отношением между организациями и разделением ответ
ственности. которые учитываются при разработке, внедрении и в операциях по техобслуживанию.
Кри терии квалификации и опыта персонала также рассмотрены в настоящем стандарте.
Ключевое понятие настоящего стандарта — это понятие уровней полноты безопасности про
граммного обеспечения. Настоящий стандарт рассматривает пять уровней полноты безопасности про
граммного обеспечения, где УПБ 0 является самым низким, а УПБ 4 — самым высоким связанным с
безопасностью уровнем полноты. Чем выше риск, возникающий из-за ошибки в программном обеспе
чении. тем выше уровень полноты безопасности программного обеспечения будет. Чем более опасны
последствия ошибки программного обеспечения, тем будет выше его уровень полноты безопасности.
Настоящий стандарт определяет методы и меры для пяти уровней полноты безопасности про
граммного обеспечения. Требуемые методы и меры для каждого из пяти уровней полноты безопас
ности программного обеспечения представлены в нормативных таблицах приложения А. В настоящей
версии требуемые методы для уровня 1 совпадают с методами для уровня 2. а требуемые методы для
уровня 3 совпадают с методами для уровня 4. Настоящий стандарт не дает рекомендаций о том. какой
уровень полноты программного обеспечения подходит для данного риска. Это решение будет зависеть от
многих факторов, включая природу приложения, насколькодругие системы выполняют функции без
опасности, также от социально-экономических факторов.
Определение процесса спецификации функций безопасности, выполняемых программным обе
спечением. входит в область применения МЭК 62278 и МЭК 62425.
Настоящий стандарт определяет те меры, которые необходимы для достижения таких требова
ний.
МЭК 62278 и МЭК 62425 требуют, чтобы был использован систематический подход:
a) для определения опасностей, оценки рисков и получения решения на основе критериев риска:
b
) определения необходимого снижения риска, удовлетворяющего критериям риска;
c) определения спецификации требований для всей системы безопасности, необходимых для га
рантированного достижения требуемого снижения риска:
d) выбора подходящей архитектуры системы;
e) планирования, контроля и управления техническими и организационными действиями, необхо
димыми для реализации спецификации требований к безопасности в системе, связанной с безопасно
стью. для которой выполняется подтверящение соответствия полноте безопасности.
Поскольку проект декомпозируется и формируется спецификация для отдельных связанных с
безопасностью систем и их компонентов, то для них далее выполняется определение уровней полноты
безопасности. В конечном счете, это приводит к требуемым уровням полноты безопасности для про
граммного обеспечения.
Современный уровень развития техники таков, что никакое применение методов гарантии каче
ства (так называемых мер предотвращения сбоев и выявления сбоев), ни применение подходов, ос
нованных на отказоустойчивом программном обеспечении, не могут гарантировать абсолютную безо
пасность системы. Нет никакого известного способа доказать отсутствие сбоев в довольно сложном,
связанном с безопасностью программном обеспечении, особенно отсутствие сбоев в проекте и специ
фикации.
Принципы, применяемые при разработке программного обеспечения с высокими требованиями
по безопасности, включают в себя, но не ограничены:
IV