Средства и системы управления железнодорожным тяговым подвижным составом (стр. 2 )

в) контроль целостности программ и данных;

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

д) защищенность от компьютерных вирусов, несанкционированного доступа, последствий отказов, ошибок и сбоев при хранении, вводе, обработке и выводе информации, возможности случайных изменений информации;

е) отсутствие свойств и характеристик, не описанных в программной документации (недекларированные возможности);

ж) соответствие свойствам и характеристикам, описанным в сопроводительной документации.

4.3 Версия ПО, установленная на ТПС, должна соответствовать версии, указанной в его декларации о соответствии требованиям безопасности.

Требования к качеству ПО, которые влияют на безопасность, приведены в таблице А.1 (приложение А).

5 Требования к документации

5.1 Основным документом, содержащим требования к ПО, является техническое задание на ПО или частное техническое задание на ПО в рамках технического задания на систему управления ТПС в целом, разрабатываемые по ГОСТ 19.201.

Примечание – В международной и европейской практике применяют аналогичный документ «спецификация требований» в соответствии с МЭК [1][1] и EN [2].

5.2 Технологические документы ПО должны определять:

- структуру и содержание исходных и отчетных документов по этапам разработки, испытаний и сопровождения ПО;

- логическую структуру программных и информационных компонентов и баз данных проекта;

- спецификации требований на внутренние межмодульные интерфейсы компонентов ПО и на интерфейсы с внешней средой;

- язык и правила программирования, идентификации компонентов, комментирования текстов программ и описаний данных;

- методы тестирования, испытаний и аттестации программных компонентов и ПО в целом;

- порядок внесения изменений в ПО;

- оформление, форматы и обозначения отчетных документов.

5.2 Эксплуатационная документация должна обеспечивать возможность освоения и эффективного применения ПО квалифицированными специалистами.

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

Эксплуатационная документация включает:

- руководства пользователей, осуществляющих установку и непосредственное управление режимами решения функциональных задач, регламентированными в системе управления ТПС;

- руководства пользователей (машиниста, начальника поезда и др.), использующих ПО по прямому назначению;

- документацию сопровождения ПО, включая руководство по управлению конфигурацией и модификации;

- справочные руководства по применению ПО;

5.3 Обязательными для поставки заказчику являются следующие документы:

- текст программы (описание файловой структуры) по ГОСТ 19.401;

- спецификация по ГОСТ 19.202;

- программа обеспечения безопасности;

- доказательство безопасности;

- руководство пользователей.

Программа обеспечения безопасности и доказательство безопасности на элементы программного обеспечения, разрабатываемые в соответствии с ГОСТ (проект) Безопасность функциональная. Политика, программа обеспечения безопасности. Доказательство безопасности объектов железнодорожного транспорта, должны быть представлены для согласования заказчику до этапа опытной эксплуатации ТПС.

6 Требования к процессу разработки программного обеспечения

6.1 Разработка программного обеспечения включает в себя следующие стадии:

- определение требований к ПО и разработка технического задания;

- разработка архитектуры ПО и проектирование программных модулей;

- кодирование;

- интеграция программных модулей;

- тестирование программных модулей;

- интеграция и валидация (тестирование) системы управления ТПС в целом;

- сопровождение и модификация ПО системы управления ТПС.

Особенности сопровождения и модификации ПО, влияющие на безопасность, приведены в приложении Б.

6.2 Определение требований к ПО осуществляют на основе анализа требований к системе управления ТПС.

Требования к ПО включают следующие характеристики для каждого компонента ПО:

- функциональные возможности, включая характеристики про­изводительности и среды функционирования компонента;

- требования к внешним интерфейсам;

- спецификация требований (функциональной) безопасности, включающая требования к функциям безопасности ПО и требования к полноте безопасности по отношению к систематическим отказам (задание уровня полноты безопасности ПО) в соответствии с МЭК [1];

- эргономические требования;

- требования к используемым данным;

- требования к установке и приемке;

- требования к документации пользователей;

- требований к эксплуатации и сопровождению.

Требования к ПО оценивают исходя из критериев их соответствия требованиям к системе управления ТПС, реализуемости и возможности проверки при тестировании.

6.3 В рамках проведения анализа требований к системе управления ТПС и анализа риска для нее, из совокупности опасностей для системы управления ТПС в целом должны быть выделены опасности и угрозы для ПО, включая угрозы информационной, функциональной безопасности и угрозы, связанные с киберзащищенностью. По результатам формируют протокол угроз.

Примечание – Протокол угроз оформляют аналогично журналу учета опасностей по ГОСТ (проект) Безопасность функциональная. Управление рисками на железнодорожном транспорте (п. 6.2.5).

Если риски по выявленным угрозам превышают допустимый уровень риска, то они должны быть снижены до допустимого уровня посредством применения различных защитных мер. Общий процесс оценки рисков в соответствии с ГОСТ (проект) Безопасность функциональная. Управление рисками на железнодорожном транспорте, а также национальными стандартами и нормативными документами, действующими на территории государств, указанных в предисловии[2].

6.4 Разработка архитектуры ПО включает следующие задачи (для каждого компонента ПО):

- трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;

- разработку и документирование программных интерфейсов ПО и баз данных;

- разработку предварительной версии документации пользователей;

- разработку предварительных плана интеграции ПО и требований к тестированию (испытаниям).

Архитектура компонентов ПО должна соответствовать предъявляемым к ним требованиям (в том числе уровню полноты безопасности ПО), а также принятым стандартам и методам проектирования.

6.5 При кодировании осуществляют написание исходного кода программы с применением выбранного языка программирования и по описанному алгоритму. При необходимости данный вид работы документируют в виде текста программы по ГОСТ 19.401.

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

6.6 Интеграция программных модулей предусматривает сборку разработанных модулей (компонентов) ПО в соответствии с планом интеграции и тестирование агрегированных компонентов.

6.7 Интеграция системы управления ТПС заключается в сборке всех ее компонентов, включая ПО и оборудование. После интеграции систему управления ТПС подвергают квалификационному (комплексному) тестированию на соответствие совокупности требований к ней.

6.8 Для обеспечения приемлемого уровня безошибочности ПО необходимо при разработке ПО:

- применять методы нисходящего проектирования;

- обеспечивать модульность программ;

- осуществлять верификацию на каждой стадии жизненного цикла ПО;

- стремиться использовать проверенные модули и библиотеки модулей;

- разрабатывать понятную документацию, которая доступна для аудита;

- проводить аттестационные испытания.

Основные приемы, используемые при разработке ПО, и необходимость их применения приведены в таблице А.2 (приложение А).

6.9 После каждой стадии разработки ПО должна быть проведена верификация, основными аспектами которой являются:

а) подтверждение выполнения ПО ТПС и его программных компонентов требований безопасности, установленных в технологической и эксплуатационной документации ПО с целью установления:

1) полноты и корректности реализации ПО ТПС функций управления и функций обеспечению безопасности движения поездов, установленных техническим заданием;

2) полноты соответствия требованиям киберзащищенности, установленных техническим заданием;

3) достаточности и обоснованности технических приемов и мероприятий, которые применены при разработке ПО;

4) полноты и корректности программ и методик испытаний;

5) полноты и корректности результатов испытаний ПО и системы управления ТПС в целом;

б) подтверждение выполнения ПО ТПС требованиям безопасности при проведении стендовых испытаний. Основными целями такой верификации являются:

1) подтверждение соответствия полученных характеристик ПО требуемым значениям;

2) проверка корректности взаимодействия между собой частей программ и аппаратуры, интегрированных на данном этапе разработки;

3) проверка работы ПО ТПС на стойкость к внешним воздействующим факторам;

4) проверка на наличие недекларированных возможностей[3].

Результаты верификации включаются в отчет о мерах по управлению функциональной безопасностью в качестве раздела документа «Доказательство безопасности» и представляют в орган по сертификации или испытательную лабораторию (центр) при испытаниях ПО третьей стороной.

7 Требования безопасности к программному обеспечению

7.1 ПО тягового подвижного состава должно обеспечивать выполнение требований а), г), д), ж) 4.2.

7.2 ПО ТПС должно управлять устройствами безопасности, обеспечивающими контроль установленных скоростей движения, периодическую проверку бдительности машиниста, препятствующими самопроизвольному уходу поезда с места его стоянки и обеспечивать автоматическую остановку поезда в случаях потери машинистом случаях работы тягового привода и другого оборудования при неисправностях аппаратов электрической, гидравлической и (или) пневматической частей не должно допускать изменений характеристик и режимов работы, которые могут привести к нарушению безопасного состояния ТПС.