Утвержден и введен в действие
Приказом Федерального агентства
по техническому регулированию
и метрологии России
от 30 ноября 2016 г. N 1881-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ЖЕЛЕЗНЫЕ ДОРОГИ
СИСТЕМЫ СВЯЗИ, СИГНАЛИЗАЦИИ И ОБРАБОТКИ ДАННЫХ. ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ И ЗАЩИТЫ НА ЖЕЛЕЗНЫХ ДОРОГАХ
Railway applications. Communication, signalling
and processing systems. Software for railway control
and protection systems
(IEC 62279:2015, IDT)
ГОСТ Р МЭК 62279-2016
Группа Т51
ОКС 13.110
Дата введения
1 января 2018 года
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Корпоративные электронные системы" на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 58 "Функциональная безопасность"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии России от 30 ноября 2016 г. N 1881-ст
4 Настоящий стандарт идентичен международному стандарту МЭК 62279:2015 "Железные дороги. Системы связи, сигнализации и обработки данных. Программное обеспечение систем управления и защиты на железных дорогах" (IEC 62279:2015, "Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Настоящий стандарт входит в группу связанных стандартов вместе с МЭК 62278:2002 "Железные дороги. Технические условия и демонстрация надежности, эксплуатационной готовности, ремонтопригодности и безопасности" и МЭК 62425:2007 "Железные дороги. Системы связи, сигнализации и обработки данных. Связанные с безопасностью электронные системы сигнализации".
МЭК 62278:2002 рассматривает проблемы крупных систем, а в МЭК 62425:2007 рассмотрен порядок утверждения отдельных систем, которые могут существовать внутри общей системы управления и защиты на железнодорожном транспорте. Настоящий стандарт уделяет внимание практическим методам создания программного обеспечения, удовлетворяющего требованиям полноты безопасности, которые определяются в результате анализа таких крупных систем.
Настоящий стандарт обеспечивает ряд требований, которым должны соответствовать разработка, внедрение и обслуживание любого связанного с безопасностью программного обеспечения, предназначенного для приложений управления и защиты на железных дорогах. Он определяет требования, связанные с организационной структурой, отношением между организациями и разделением ответственности, которые учитываются при разработке, внедрении и в операциях по техобслуживанию. Критерии квалификации и опыта персонала также рассмотрены в настоящем стандарте.
Ключевое понятие настоящего стандарта - это понятие уровней полноты безопасности программного обеспечения. Настоящий стандарт рассматривает пять уровней полноты безопасности программного обеспечения, где УПБ 0 является самым низким, а УПБ 4 - самым высоким связанным с безопасностью уровнем полноты. Чем выше риск, возникающий из-за ошибки в программном обеспечении, тем выше уровень полноты безопасности программного обеспечения будет. Чем более опасны последствия ошибки программного обеспечения, тем будет выше его уровень полноты безопасности.
Настоящий стандарт определяет методы и меры для пяти уровней полноты безопасности программного обеспечения. Требуемые методы и меры для каждого из пяти уровней полноты безопасности программного обеспечения представлены в нормативных таблицах приложения A. В настоящей версии требуемые методы для уровня 1 совпадают с методами для уровня 2, а требуемые методы для уровня 3 совпадают с методами для уровня 4. Настоящий стандарт не дает рекомендаций о том, какой уровень полноты программного обеспечения подходит для данного риска. Это решение будет зависеть от многих факторов, включая природу приложения, насколько другие системы выполняют функции безопасности, также от социально-экономических факторов.
Определение процесса спецификации функций безопасности, выполняемых программным обеспечением, входит в область применения МЭК 62278 и МЭК 62425.
Настоящий стандарт определяет те меры, которые необходимы для достижения таких требований.
МЭК 62278 и МЭК 62425 требуют, чтобы был использован систематический подход:
a) для определения опасностей, оценки рисков и получения решения на основе критериев риска;
b) определения необходимого снижения риска, удовлетворяющего критериям риска;
c) определения спецификации требований для всей системы безопасности, необходимых для гарантированного достижения требуемого снижения риска;
d) выбора подходящей архитектуры системы;
e) планирования, контроля и управления техническими и организационными действиями, необходимыми для реализации спецификации требований к безопасности в системе, связанной с безопасностью, для которой выполняется подтверждение соответствия полноте безопасности.
Поскольку проект декомпозируется и формируется спецификация для отдельных связанных с безопасностью систем и их компонентов, то для них далее выполняется определение уровней полноты безопасности. В конечном счете, это приводит к требуемым уровням полноты безопасности для программного обеспечения.
Современный уровень развития техники таков, что никакое применение методов гарантии качества (так называемых мер предотвращения сбоев и выявления сбоев), ни применение подходов, основанных на отказоустойчивом программном обеспечении, не могут гарантировать абсолютную безопасность системы. Нет никакого известного способа доказать отсутствие сбоев в довольно сложном, связанном с безопасностью программном обеспечении, особенно отсутствие сбоев в проекте и спецификации.
Принципы, применяемые при разработке программного обеспечения с высокими требованиями по безопасности, включают в себя, но не ограничены:
- нисходящие методы разработки;
- модульный принцип;
- проверка каждой стадии жизненного цикла разработки;
- проверенные модули и библиотеки модулей;
- понятная документация и прослеживаемость;
- аудирование документов;
- подтверждение соответствия;
- оценка;
- управление конфигурацией и управление изменениями;
- надлежащее рассмотрение проблем компетентности организации и персонала.
Спецификация требований безопасности к системе идентифицирует все функции безопасности, определенные для программного обеспечения, и определяет их уровни полноты безопасности. В соответствии с настоящим стандартом, как показано на рисунке 1, последовательно выполняются следующие функциональные шаги:
a) определение спецификации требований для программного обеспечения и параллельно рассмотрение архитектуры программного обеспечения. В рамках формирования архитектуры программного обеспечения разрабатывается основная стратегия безопасности для программного обеспечения и его уровня полноты безопасности (см. 7.2 и 7.3);
b) проектирование, разработка и тестирование программного обеспечения выполняется согласно плану обеспечения качества программного обеспечения, уровню полноты безопасности программного обеспечения и жизненному циклу программного обеспечения (см. 7.4 и 7.5);
c) реализация интеграции программного обеспечения и программного обеспечения с аппаратными средствами на целевых аппаратных средствах, а также проверка функциональности (см. 7.6);
d) выполнение приемки и внедрение программного обеспечения (см. 7.7 и 9.1);
e) если в период эксплуатации программного обеспечения требуется его поддержка, то повторно выполняются надлежащие процедуры настоящего стандарта (см. 9.2).
Рисунок 1 - Маршрутная карта программного обеспечения
С разработкой программного обеспечения связаны несколько действий таких, как тестирование (см. 6.1), проверка (см. 6.2), подтверждение соответствия (см.
Для просмотра документа целиком скачайте его >>>
