Поездная коммуникационная сеть

10.1.2.1 Коммуникационная сеть электропоезда (в дальнейшем сеть поезда) должна быть выполнена в соответствии с требованиями по передаче информации в поезде стандартов IEC 61375, UIC 556, европейских стандартов ISO и CENELEC.

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

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

10.1.2.3 Сеть поезда (соответственно по протоколам работы и кодам доступа, представляемых Заказчику) должна обеспечивать двухстороннюю связь при передаче информационной, диагностической информации и управляющих команд между поездной бригадой, ремонтным персоналом депо и оборудованием вагонов электропоезда.

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

10.1.2.5 Сеть поезда должна иметьрезервированиепоезднойшинынааппаратноми программном уровне.

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

10.1.2.7 Должно быть представлено описание аппаратных средств сети поезда, включающее линии связи, узлы стыковки и т. п., средства их тестирования.

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

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

10.1.2.10 Каждое оборудование, подключенное к сети,должноиметь индикацию, отражающую работоспособность (наличие питания, обмена по сети, аварийной ситуации и т.п.)

10.1.2.11 Должно быть обеспечено соблюдение норм электромагнитной совместимости по стандарту EN 50121, ГОСТР 50839.

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

Программное обеспечение

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

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

10.1.3.2 Программные средства железнодорожного подвижного состава, как встраиваемые, так и поставляемые на материальных носителях, в соответствии с техническими регламентами Таможенного союза от 15.07.2011 (№001/2011 и № 002/2011) должны обеспечивать:

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

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

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

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

10.1.3.4 Язык программирования должен быть определен полно и однозначно. Его следует использовать вместе с конкретным стандартом кодирования и при ограниченном подмножестве команд.

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

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

10.1.3.7 Используемые интерфейсы при разработке ПО и отдельных модулей системы должны быть стандартными и согласовываться с Заказчиком. В случае нетиповых решений они также должны быть согласованы с Заказчиком и переданы на экспертизу с подробным описанием на русском языке и протоколами испытаний.

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

10.1.3.9 Спецификация требований наПО должна соответствовать спецификации требований на систему и спецификации требований на безопасность системы

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

10.1.3.11 ПО должно содержать процедуру диагностики отказов и ошибок во всех частях оборудования (в датчиках, устройствах ввода/вывода, логических решающих устройствах, выходных элементах, в линиях связи и в памяти). В случае обнаружения в системе ошибки или отказа, система должна иметь возможность продолжать функционирование с объявлением возможного набора функций и ограничений по безопасности, но при условии отключения резервированного элемента или целой части системы, дающей ошибку.

10.1.3.12 Любые ограничения между аппаратными средствами и ПО должны быть идентифицированы и зарегистрированы в Спецификацию требований ПО.

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

10.1.3.14 На каждом этапе жизненного цикла (стадии спецификации требований, разработки, тестирования, интеграции, установки и обслуживания) должна быть проведена назначенная экспертиза. Этап может считаться законченным только после получения положительных результатов оценки.

10.1.3.15 Описание ПО должно позволять без дополнительной доработки использовать его для анализа и испытаний на качество и безопасность.

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

10.1.3.17 При использовании элементов готовых программных продуктов или заимствованных из других систем они должны быть объявлены. Должны быть представлены протоколы испытаний таких продуктов, включая для безопасного ПО «Доказательство безопасности». Разработчик несет ответственность за работу представленных им заимствованных элементов ПО независимо от принадлежности права собственности на этот продукт.

10.1.3.18 Элементы ПО, связанные с функциями, влияющими на безопасность, должны быть оговорены исполнителем отдельно.Программа обеспечения безопасности и Доказательство безопасности на такое ПО, составленные по рекомендациям ГОСТ Р 54504, должны быть представлены заказчику до этапа опытной эксплуатации. Должно быть показано, что каждое из требований было выполнено в соответствии с уровнем функциональной безопасности ПО. Допускается разработка Доказательства безопасности ПОв составе доказательства безопасности на систему в целом.

10.1.3.19 Порядок передачи ПО. В случае наличия специальной операционной среды для проверки правильности функционирования, ПО передается Заказчику вместе с инструкцией по ее инсталляции и пользованию. Уровень покрытия тестированием должен быть не менее 98 %.

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

10.1.3.20 Должен быть разработан программный продукт для тестирования ПО. Заказчику представляются специализированные аппаратные средства, позволяющие проверить ПОпо всем реализуемым функциям, или их имитатор на ПЭВМ с доказательством корректности работы имитатора. Разработчик несет ответственность за работу отладочных и тестирующих средств, обеспечивающих проверку ПО, и обязан устранить сбои и отказы в работе этих средств бесплатно на весь период действия договора и дополнительно в течение 5-ти лет подконтрольной эксплуатации.

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

10.1.3.21 Специализированные инструментальные средства разработки ПО, его отладка и тестирование передаются Разработчиком Заказчику, проводится обучение работе с ними, поддерживается их работоспособность на все время работы системы.

10.1.3.22 На испытания, тестирование, экспертизу Разработчик представляет:

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

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

- материалы разработки (проекты, пояснительные записки, тексты программ, спецификации, описания и т. п.) – по запросу испытателей;

- документы и материалы по испытаниям – по запросу испытателей; эксплуатационную документацию (формуляр, руководство пользователя, руководство по установке и др.).

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

10.1.3.24 ПО систем электропоезда должно соответствовать требованиям функциональной безопасности ГОСТ Р 61508-3.

10.1.3.25 Для подтверждения соответствия требованиям ГОСТ Р МЭК 61508-3 должно быть показано, что каждое из требований было выполнено в соответствии с уровнем безопасности ПО и, следовательно, цель раздела была достигнута.

10.1.3.26 ПО систем электропоезда должно соответствовать требованиям качества по ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению», ГОСТ Р МЭК 61508-3-2012

10.1.3.27 Должна быть произведена классификация микропроцессорных систем электропоезда по уровню значимости информации и классу защищенности в соответствии с требованиями, утвержденными приказом ФСТЭК №31 от 14.03.2014 г.

10.1.3.27.1 Комплексная система обеспечения безопасности движения на высокоскоростных участках железных дорог» (КСОБ-ВСМ) относится к средствам с третьим уровнем значимости информации (УЗ 3) и третьим классом защищенности (К3).

10.1.3.27.2 Для других систем электропоезда провести классификацию по уровню значимости информации и классу защищенности в соответствии с распоряжением ОАО «РЖД» от 03.03.2015 г. №543р. Сформированные в результате классификации требования информационной безопасности должны быть включены в техническое задание.

10.1.3.27 Должны быть реализованы меры защиты информации в автоматизированной системе, обеспечивающие выполнение требований, утвержденных приказом ФСТЭК №31 от 14.03.2014 г.

10.1.3.28 Должна быть произведена классификация ПОпо уровню контроля отсутствия в нем недекларированных возможностей в соответствии с требованиями руководящего документа «Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации Классификация по уровню контроля отсутствия недекларированных возможностей» (Гостехкомиссия России, 1999).

10.1.3.29 ПОсистем электропоезда подлежит сертификации на отсутствие недекларированных возможностей в соответствии с требованиями СТО РЖД 02.049-2014 и руководящего документа «Средства и системы управления железнодорожным подвижным составом и высокоскоростным железнодорожным транспортом Требования к программному обеспечению», утвержденного ОАО «РЖД» 17.09.2013г.

10.1.3.30 ПОсистем электропоезда подлежит декларированию соответствия по требованиям технических регламентов Таможенного союза от 15.07.2011 (№001/2011 и № 002/2011)

10.1.3.31 Подтверждение выполнения требований функциональной и информационной безопасности к ПО микропроцессорных систем электропоезда должно осуществляться путем проведения оценки соответствия.

10.1.3.32 ПОсистем электропоезда подлежит оценке соответствия требованиям функциональной и информационной безопасности, а также киберзащищенности в соответствии с СТО РЖД 02.049-2014.

10.1.3.33 Для оценки соответствия должна быть разработана технологическая и эксплуатационная документация, отвечающая требованиям СТО РЖД 02.049-2014 и руководящего документа «Средства и системы управления железнодорожным подвижным составом и высокоскоростным железнодорожным транспортом Требования к программному обеспечению», утвержденного ОАО «РЖД» 17.09.2013г. и требованиям стандартов РФ Единой системы программной документации.

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

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

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

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

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

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

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

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

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

- перечень отчетных документов.

10.1.3.33.2 Эксплуатационные документы ПО включают:

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

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

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

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

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

10.1.3.34 Для оценки соответствия должно быть разработано Задание по безопасности в соответствии с ГОСТ Р ИСО/МЭК 15408-3.

10.1.3.35 Для оценки соответствия должна быть проведена оценка рисков для ПО системы в соответствии с ГОСТ Р 54505 и ГОСТ Р ИСО/МЭК 27005.

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

10.1.3.37 Результаты оценки рисков должны быть задокументированы. Отчет об оценке риска в соответствии с СТО РЖД 02.049 в общем случае должен включать:

- описание цели и масштаба проведения оценки;

- описание объекта оценки риска и его функций или оцениваемой ситуации;

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

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

- ограничения, допущения, предположения и обоснование гипотез;

- метод оценки рисков;

- исходные положения, ограничения и обоснование метода;

- описание идентифицированных опасностей и рисков;

- исходные данные, их источники и проверка;

- результаты анализа риска и оценка их достоверности;

- анализ факторов чувствительности и неопределенности;

- результаты оценивания риска;

- критические допущения и иные факторы, подлежащие мониторингу;

- обсуждение результатов;

- выводы и рекомендации;

- ссылки на справочные документы.

10.1.3.38 Для проведения исследований по оценке информационной и функциональной безопасности в комплексном рассмотрении Разработчиком должны предъявляться:

- программно-аппаратный комплекс МПСУ;

- техническая и эксплуатационная документация;

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

- описание архитектуры технологического процесса;

- протоколы заводских испытаний;

- алгоритмы ПО и их описание;

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

- результаты сертификационных испытаний на соответствие требований ФСТЭК России.

10.1.3.39 Модификация сертифицированного ПО может производиться только после подачи заявки на изменения в соответствии с установленными в Приложении 1 Руководящего документа, утвержденного ОАО «РЖД» 17.09.2013г, процедурами модификации ПО.

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

10.1.3.41 Порядок проведения экспертизы модификации ПО определен ГОСТ Р 52980 и ГОСТ Р МЭК 61508-3.

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

10.1.3.43 Экспертизу модифицированного ПО должен проводить испытательный центр (лаборатория), который проводил сертификационные испытания.

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

10.1.3.45 Заявка на изменение сертифицированного ПО может быть подана Разработчиком, Изготовителем или Заказчиком.

10.1.3.46 Заявка на изменение сертифицированного ПО подается в следующих случаях:

− безопасность в процессе эксплуатации, по мнению подателя заявки, ниже необходимой или заданной;

− выявление скрытых ошибок ПО;

− ошибки в требованиях к функциональным характеристикам ПО, выявленные в процессе эксплуатации;

− модификация комплекса технических средств, замена элементной базы или модификация использования комплекса технических средств;

− изменение требований по общей безопасности.

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

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

10.1.3.49 Изменения в документации должны быть проанализированы экспертами испытательного центра, в котором проводились испытания и экспертиза документации.

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

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

10.1.3.52 Если решение отсрочено, Разработчику следует предоставить рекомендации, как действовать до повторного рассмотрения.

10.1.3.53 Если изменение отклонено, то Разработчику следует информировать ответственных за инициацию внесения изменений, чтобы снять предложенное изменения с рассмотрения

10.1.3.54 Процесс изменения заканчивается формированием нового базового состояния. Утвержденное изменение записывается на CD-диск, идентифицируется и в дальнейшем CD-диск с изменениями используется как эталонный диск с проставлением даты формирования диска и приложением протокола идентификации.

Аппаратные средства

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

10.1.4.2 Система управления должна обеспечивать возможность интеграции с отдельными новыми устройствами, узлами и компонентами.

10.1.4.3 Параллельно с разработкой систем управления должно разрабатываться, а затемпоставляться в депо сервисное оборудование.

Требования по климатическим и механическим воздействиям

10.1.5.1 Корпуса блоков по степени защиты от проникновения воды и посторонних предметов должны соответствовать степени IP54 по ГОСТ 14254.

10.1.5.2 Аппаратура управления электропоездом должна обеспечивать надежную эксплуатацию в климатических условиях температур окружающей среды от минус 40 ºC до +40 ºC. Оборудование, обеспечивающее безопасность, должно функционировать надлежащим образом при температуре отминус 50 ºС.

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

Управление электропоездом

10.2.1Функциональные требования

10.2.1.1 Система управления электропоездом должна обеспечивать все эксплуатационные режимы работы электропоезда (таблица 1.2).

10.2.1.2 Управление электропоездом, включая режим движения соединённых электропоездов, должно быть обеспечено только из одной кабины машиниста.

10.2.1.3 Время реагирования систем и оборудования электропоезда на команды управления машиниста или подсистемы автоведения, в том числе связанных с безопасностью движения, определяется Разработчиком на этапе эскизного проекта и согласовывается с Заказчиком, но не должно превышать 0,5 с.

Автоведение

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

10.2.2.2 В режиме автоведения система обеспечивает:

− расчет и реализацию траекториидвиженияэлектропоезда в функции путис управлением тягой и всеми видами торможения, с учётом требований и ограничений, налагаемых комплексной системой безопасности КСОБ-ВСМ;

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

− автоматическое выполнение режимов разгона, поддержания скорости, выбега и торможения под ограничения скорости, сигналыавтоблокировки.

10.2.2.3 Система управления должна обеспечивать управление движением электропоезда в режимах автоведения, советчика и ручного управления, в том числе при работе по системе многих единиц.

10.2.2.4 В режиме советчика управление электропоездом должно осуществляться машинистом с учётомвыдаваемыхна пульт управлениярекомендаций по оптимальному ведению электропоезда.

10.2.2.5 Параметры режима управления должны быть записаны в энергонезависимую память, используемую для записи поездки.

10.2.2.6 На этапе технического проекта должно быть произведено подробное описание функциональных возможностей и характеристик подсистемы управления в рамках автоведения.

Информационное обеспечение

10.2.3.1 Должно быть обеспечено информирование:

− локомотивной бригады;

− поездной бригады;

− ремонтных служб депо.

10.2.3.2 Каждой группе пользователей должна быть определена и согласована с Заказчиком доступная для них информация на этапе подготовки эскизного проекта.