ГОСТ Р МЭК 62279-2016

     
Группа Т51

     
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Железные дороги

СИСТЕМЫ СВЯЗИ, СИГНАЛИЗАЦИИ И ОБРАБОТКИ ДАННЫХ. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ И ЗАЩИТЫ НА ЖЕЛЕЗНЫХ ДОРОГАХ

Railway applications. Communication, signalling and processing systems. Software for railway control and protection systems

ОКС 13.110

Дата введения 2018-01-01

     

Предисловие

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 - самым высоким связанным с безопасностью уровнем полноты. Чем выше риск, возникающий из-за ошибки в программном обеспечении, тем выше уровень полноты безопасности программного обеспечения будет. Чем более опасны последствия ошибки программного обеспечения, тем будет выше его уровень полноты безопасности.

Настоящий стандарт определяет методы и меры для пяти уровней полноты безопасности программного обеспечения. Требуемые методы и меры для каждого из пяти уровней полноты безопасности программного обеспечения представлены в нормативных таблицах приложения А. В настоящей версии требуемые методы для уровня 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).

С разработкой программного обеспечения связаны несколько действий таких, как тестирование (см. 6.1), проверка (см. 6.2), подтверждение соответствия (см. 6.3), оценка (см. 6.4), контроль качества (см. 6.5), а также управление модификацией и изменениями (6.6).

Представлены требования к средствам поддержки (см. 6.7) и системам, которые сконфигурированы с помощью данных приложения или алгоритмов (см. 8).

Также даны требования к независимости ролей и компетентности штата, участвующего в разработке программного обеспечения (см. 5.1, 5.2 и приложение В).

Настоящий стандарт не рассматривает использование конкретного жизненного цикла разработки программного обеспечения. Однако в 5.3, рисунки 3 и 4, и 7.1 представлены иллюстративный пример жизненного цикла и необходимые комплекты документации.

В результате оценки различных методов/мер для пяти уровней полноты безопасности программного обеспечения были сформированы таблицы, представленные в приложении А. В этих таблицах есть соответствующие ссылки на библиографию, дающую краткое описание каждого метода/меры со ссылками на дальнейшие источники информации. Библиография методов представлена в приложении D.

     
Рисунок 1 - Маршрутная карта программного обеспечения

     1 Область применения

1.1 Настоящий стандарт определяет процедуры и технические требования для разработки программируемых электронных систем для использования в приложениях управления и защиты на железных дорогах. Настоящий стандарт нацелен на использование в любой области, где важна безопасность. Такие системы могут быть реализованы, используя специализированные микропроцессоры, программируемые логические контроллеры, многопроцессорные распределенные системы, системы на базе центрального процессора более широкого масштаба или другую архитектуру.

1.2 Настоящий стандарт применим исключительно к программному обеспечению и взаимодействию между программным обеспечением и системой, частью которой оно является.

1.3 Настоящий стандарт не применяется для программного обеспечения, которое было идентифицировано, как не оказывающее влияние на безопасность, т.е. для программного обеспечения, отказы которого не могут влиять ни на какие идентифицированные функции безопасности. Понятие УПБ 0 введено потому, что при оценке риска присутствует неопределенность и даже при идентификации опасностей. По крайней мере, требования УПБ 0 настоящего стандарта выполнены для программного обеспечения, оказывающего влияние на безопасность функций, у которых значение УПБ ниже УПБ 1.

1.4 Настоящий стандарт применяется ко всему связанному с безопасностью программному обеспечению, используемому в системах управления и защиты на железных дорогах, включая:

- прикладное программирование;

- операционные системы;

- инструменты поддержки;

- встроенное микропрограммное обеспечение.

Прикладное программирование включает высокоуровневое программирование, низкоуровневое программирование и специальное программирование (например, лестничная логика программируемого логического контроллера).

1.5 Настоящий стандарт также рассматривает использование существующего ранее программного обеспечения и инструментальных средств. Такое программное обеспечение может использоваться, если выполнены конкретные требования 7.3.4.7 и 6.5.4.16 для уже существующего программного обеспечения и требования 6.7 для инструментальных средств.

1.6 Программное обеспечение, разработанное в соответствии с любой редакцией настоящего стандарта, будет считаться как удовлетворяющее соответствующим требованиям и не должно рассматриваться как ранее существующее программное обеспечение.

1.7 Настоящий стандарт полагает, что современное проектирование приложений часто использует универсальное программное обеспечение, которое является базовым для различных приложений. Такое универсальное программное обеспечение конфигурируется данными, алгоритмами или тем и другим при создании исполнимого программного обеспечения для приложения. Разделы 1-6 и 9 настоящего стандарта применяются к универсальному программному обеспечению, а также к данным приложения или алгоритмам. Раздел 7 применяется только для универсального программного обеспечения, а раздел 8 содержит конкретные требования для данных приложения или алгоритмов.

1.8 Настоящий стандарт не предназначен для решения коммерческих проблем. Они должны быть основной частью любого договорного соглашения. Но в любой коммерческой ситуации необходимо внимательно рассмотреть все разделы настоящего стандарта.

1.9 Настоящий стандарт не предполагает рассматривать существующие системы. Поэтому он применяется, прежде всего, к новым разработкам и только полностью применяется к существующим системам, если они подвергаются существенным модификациям. Для незначительных изменений применяется только 9.2. Оценщик анализирует доказательства, представленные в документации на программное обеспечение, чтобы подтвердить, соответствуют ли они характеру и области применения изменений программного обеспечения. Однако настоятельно рекомендуется применять настоящий стандарт во время обновлений и сопровождения существующего программного обеспечения.

     2 Нормативные ссылки

В настоящем стандарте использованы следующие международные стандарты*. Для датированных ссылок применяют только указанное издание ссылочного стандарта. Для недатированных ссылок применяют последнее издание ссылочного стандарта.

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - Примечание изготовителя базы данных.     

IEC 62278:2002, Railway applications - Specification and demonstration of reliability, availability, maintainability and safety (RAMS) (Железные дороги. Технические условия и демонстрация надежности, эксплуатационной готовности, ремонтопригодности и безопасности (RAMS))

ISO/IEC 90003:2014, Software engineering - Guidelines for the application of ISO 9001:2008 to computer software (Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов)

ISO/IEC 25010 series, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов)

ISO 9000, Quality management systems - Fundamentals and vocabulary (Системы менеджмента качества. Основные положения и словарь)