Испытания программных средств продукции железнодорожного транспорта и инфраструктуры — это документированная проверка конкретной версии программного обеспечения, применяемого в составе подвижного состава, систем управления, диагностики, регистрации, связи и железнодорожной автоматики. Цель работ — получить объективные доказательства соответствия ПО применимым требованиям технических регламентов, стандартов, технической и программной документации.
Протокол испытаний входит в доказательную базу, но не заменяет декларацию
Испытательная лаборатория идентифицирует объект, проводит предусмотренные методикой проверки и оформляет протокол. Заявитель использует протокол вместе с другими документами при подтверждении соответствия железнодорожной продукции. Форму подтверждения, состав доказательств и применимые требования определяют по конкретному объекту и соответствующему техническому регламенту.
Для чего проводят испытания программных средств железнодорожного транспорта
Современная железнодорожная продукция управляется программными средствами на разных уровнях: от встроенного кода контроллера до распределённой системы диспетчеризации. ПО получает сигналы от датчиков, формирует команды исполнительным устройствам, диагностирует состояние оборудования, отображает информацию машинисту или оператору, регистрирует события и поддерживает обмен данными между бортовыми и стационарными подсистемами.
Ошибка в программе, неверная конфигурация, подмена модуля или несовместимость версий могут повлиять на функции изделия даже при исправной аппаратной части. Поэтому испытания должны подтвердить не только наличие заявленных функций, но и то, что проверялся однозначно определённый программный объект в установленной конфигурации.
Испытания могут быть необходимы:
- изготовителю железнодорожной продукции — для формирования доказательной базы соответствия;
- разработчику ПО — для независимой проверки реализации требований и подготовки релиза к поставке;
- заявителю при декларировании — для получения протокола аккредитованной испытательной лаборатории;
- органу по сертификации — при рассмотрении доказательных материалов по продукции;
- заказчику или владельцу инфраструктуры — для приёмки, ввода в эксплуатацию и контроля изменений;
- интегратору — для подтверждения совместимости программных и аппаратных компонентов комплекса.
Идентифицировать объект
Зафиксировать наименование, версию, конфигурацию, перечень значимых файлов и цифровые идентификаторы программного средства.
Проверить требования
Связать требования технического регламента, стандарта, ТУ, ТЗ и программной документации с конкретными проверками.
Получить воспроизводимые результаты
Провести испытания по согласованной методике, сохранить исходные данные, журналы, наблюдения и критерии оценки.
Сформировать доказательства
Оформить протокол с выводами по каждому проверяемому требованию и передать его заявителю.
Аккредитация лаборатории и границы применимости работ
Испытания проводит Испытательная лаборатория ФБУ «Научно-исследовательский центр прикладной метрологии — Ростест». Уникальный номер записи об аккредитации в национальной системе аккредитации — RA.RU.21БН02. Адрес места осуществления деятельности, указанный в приложенной области аккредитации: 119361, Москва, улица Озёрная, дом 46.
В документах области аккредитации от 8 апреля 2025 года прямо указаны программные средства для автоматизированных систем оперативного управления движением поездов; программные средства железнодорожного транспорта для управления технологическими процессами, связанными с безопасностью движения и информационной безопасностью; устройства, комплексы и системы управления, контроля и безопасности железнодорожного подвижного состава и их программные средства.
Область охватывает методы оценки качества, документации, структуры и идентификации ПО, функциональных характеристик, защиты информации, функциональной безопасности, интерфейсов, жизненного цикла, тестируемости, анализируемости, модифицируемости, восстанавливаемости, регистрации событий и других характеристик — в пределах конкретных документов и позиций области аккредитации.
Перед заключением договора область проверяется по актуальной записи реестра
Область аккредитации может изменяться. Представленные на этой странице файлы отражают редакцию от 8 апреля 2025 года и используются как справочный источник. Возможность выполнения конкретной проверки подтверждается после анализа объекта, требований и актуальной области аккредитации на дату договора.
Нормативная основа испытаний железнодорожного ПО
Единый перечень документов для всех проектов отсутствует. Применимый набор формируется по типу железнодорожной продукции, её назначению, заявленным функциям ПО, выбранной форме подтверждения соответствия и требованиям технической документации.
Технические регламенты ЕАЭС
ТР ТС 001/2011
«О безопасности железнодорожного подвижного состава». Применяется к подвижному составу и его составным частям в пределах установленной регламентом области.
ТР ТС 002/2011
«О безопасности высокоскоростного железнодорожного транспорта». Учитывается, если объект относится к высокоскоростному железнодорожному транспорту.
ТР ТС 003/2011
«О безопасности инфраструктуры железнодорожного транспорта». Применим к объектам инфраструктуры, автоматике, телемеханике и связанным комплексам в соответствующей части.
Требования изготовителя и заказчика
Технические условия, техническое задание, конструкторская, эксплуатационная и программная документация конкретизируют функции и критерии проверки.
Профильные и общесистемные стандарты
- ГОСТ 34009-2016 — требования к встроенному и прикладному программному обеспечению бортовых систем управления железнодорожным тяговым подвижным составом;
- ГОСТ 34008-2016 — правила подготовки обоснования безопасности железнодорожной техники;
- ГОСТ 34012-2016 — общие технические требования к аппаратуре железнодорожной автоматики и телемеханики;
- ГОСТ 33435-2023 — требования безопасности и методы контроля устройств управления, контроля и безопасности железнодорожного подвижного состава;
- ГОСТ Р 8.654-2015 и ГОСТ Р 8.883-2015 — при проверке документации, структуры, идентификации, алгоритмов, защиты, хранения и передачи данных;
- ГОСТ Р МЭК 61508, ГОСТ Р 52980 и связанные документы — при наличии задач функциональной безопасности и в пределах применимости;
- стандарты серии ГОСТ Р ИСО/МЭК 25000 — при оценке качества программного продукта и процессов оценки;
- ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045 — когда в согласованный состав работ включены характеристики информационной безопасности;
- согласованная методика испытаний, устанавливающая проверяемые требования, сценарии, исходные данные, ожидаемые результаты и критерии соответствия.
Ссылка на стандарт в области аккредитации сама по себе не означает, что весь документ безусловно применяется к любому объекту. В методике указывают конкретные положения, характеристики и методы, относящиеся к заявленному программному средству.
Как протокол испытаний используется при подтверждении соответствия
Для ряда программных средств железнодорожного назначения подтверждение соответствия проводится в форме декларирования. Заявитель принимает декларацию и несёт ответственность за полноту и достоверность доказательств. Протокол испытательной лаборатории подтверждает результаты проверки конкретной идентифицированной версии ПО и может быть включён в комплект доказательных материалов.
Заявитель определяет объект
Устанавливает продукцию, программное средство, технический регламент, схему и требования, которые должны быть подтверждены.
Лаборатория проводит испытания
Проверяет согласованные характеристики, фиксирует версию, условия, исходные данные и фактические результаты.
Оформляется протокол
В документ включаются методы, результаты и выводы в пределах выполненных испытаний.
Формируется доказательная база
Заявитель объединяет протокол с технической документацией и иными требуемыми доказательствами.
Протокол не подтверждает автоматически соответствие всей железнодорожной продукции и не гарантирует регистрацию декларации. Его применимость определяется областью испытаний, полнотой программы, идентификацией объекта и требованиями конкретной процедуры.
Какие программные средства могут быть объектом испытаний
Объектом может быть автономное, встроенное или распределённое программное средство, а также программная часть комплекса, если её состав и границы можно однозначно установить.
Бортовые системы управления
ПО локомотивов, электропоездов, тепловозов, моторвагонного, специального и высокоскоростного подвижного состава.
Торможение и тяговый привод
Алгоритмы тормозного управления, противоюзной защиты, тягового привода и вспомогательного оборудования.
Контроллеры и вычислительные блоки
Встроенное ПО контроллеров, шлюзов, модулей ввода-вывода, устройств связи и вычислительных комплексов.
Диагностика и мониторинг
ПО технической диагностики, мониторинга состояния, прогнозирования отказов и обслуживания по состоянию.
Регистрация и архивирование
Регистраторы событий, журналы, диагностические архивы, системы хранения и последующего анализа данных.
Интерфейсы машиниста и оператора
Системы отображения, сигнализации, управления режимами и предоставления информации персоналу.
Железнодорожная автоматика
Программные средства ЖАТ, диспетчеризации, оперативного управления движением и инфраструктурных комплексов.
Программно-аппаратные комплексы
Нераздельные комплексы, в которых функции определяются совместной работой аппаратуры, встроенного и прикладного ПО.
Что проверяется при испытаниях программного средства
Состав проверок определяется методикой. Для одного проекта достаточно идентификации и функциональных сценариев, для другого требуется испытательный стенд, имитация отказов, анализ журналов, проверка восстановления и оценка значимых алгоритмов.
| Направление проверки | Что устанавливается | Примеры доказательств |
|---|---|---|
| Документация | Полнота описания назначения, функций, архитектуры, интерфейсов, алгоритмов, режимов и ограничений. | ТЗ, ТУ, описание программы, руководства, схемы, таблица требований. |
| Идентификация | Однозначность версии, конфигурации и состава значимых программных компонентов. | Номер версии, перечень файлов, контрольные суммы, журнал сборки, подпись релиза. |
| Функциональность | Выполнение заявленных функций и корректная реакция на входные воздействия. | Тестовые сценарии, исходные данные, журналы, снимки экрана, данные стенда. |
| Алгоритмы | Соответствие логики управления, диагностики и обработки данных установленным требованиям. | Контрольные примеры, эталонные расчёты, модели сигналов, сопоставление результатов. |
| Интерфейсы и обмен | Корректность форматов, команд, состояний, тайм-аутов и обработки нарушений связи. | Трассы протоколов, журналы обмена, имитаторы, сообщения об ошибках. |
| Защита и целостность | Устойчивость к несанкционированному изменению ПО и значимых данных в заявленных пределах. | Роли, права, контроль целостности, журналирование, реакция на подмену файлов. |
| Диагностика и регистрация | Фиксация событий, ошибок, отказов и действий персонала с необходимой прослеживаемостью. | Журналы событий, коды ошибок, временные метки, архивы диагностических данных. |
| Восстановление | Поведение после перезапуска, потери питания, нарушения связи или повреждения данных. | Протокол воздействия, состояние до и после, восстановленные настройки и журналы. |
Проверка безопасного поведения и негативных сценариев
Для ПО, связанного с управлением и безопасностью, одних позитивных тестов недостаточно. Методика должна учитывать предусмотренные документацией отказы и недостоверные входные данные. При этом испытания не заменяют полный анализ функциональной безопасности изделия, если такая процедура требуется отдельно.
В зависимости от объекта могут проверяться:
- потеря, задержка, искажение или выход входного сигнала за допустимый диапазон;
- нарушение связи между контроллерами, датчиками, исполнительными и сервисными системами;
- отсутствие или несогласованность обязательных данных;
- отключение и восстановление питания, перезапуск программного модуля или вычислительного блока;
- ошибка загрузки конфигурации, несовместимость версий или нарушение контрольной суммы;
- переполнение архива, недостаток памяти, недоступность внешнего хранилища;
- попытка выполнения запрещённой команды или изменение защищённого параметра;
- переход в предусмотренное безопасное или ограниченное состояние и регистрация причины такого перехода.
Критерий безопасного состояния должен быть установлен до испытаний
Лаборатория не назначает безопасное состояние произвольно. Ожидаемая реакция системы должна следовать из требований к изделию, анализа рисков, технического задания, алгоритмов управления и эксплуатационной документации.
Какие документы и материалы нужны для проведения испытаний
Минимальный комплект зависит от объекта, но материалы должны позволять понять, что именно проверяется, какие требования предъявлены и как воспроизвести заявленные режимы.
Документы об объекте и требованиях
- заявка и краткое описание цели испытаний;
- сведения о железнодорожной продукции или системе, в состав которой входит ПО;
- перечень применимых положений технического регламента, стандартов, ТУ и ТЗ;
- описание назначения, области применения, архитектуры и границ программного средства;
- описание функций, алгоритмов, интерфейсов и последовательности обработки данных;
- руководства по установке, загрузке, эксплуатации, диагностике и обслуживанию;
- описание журналов, кодов ошибок, режимов отказа и восстановления;
- описание механизмов защиты и управления правами доступа.
Материалы для идентификации и воспроизведения испытаний
- номер версии, обозначение сборки и сведения о конфигурации;
- перечень значимых модулей, файлов, библиотек и встроенных компонентов;
- алгоритм расчёта и эталонные значения цифровых идентификаторов;
- инсталляционный комплект, образ программного носителя или доступ к стенду;
- тестовые наборы, имитаторы, контрольные примеры и ожидаемые результаты;
- сведения об аппаратной и системной платформе;
- матрица прослеживаемости «требование — проверка — доказательство», если она ведётся разработчиком.
Исходный код не является безусловно обязательным для каждой работы. Он или отдельные фрагменты могут потребоваться, если существенный алгоритм, механизм защиты или обработку исключительной ситуации невозможно достоверно подтвердить по документации, исполняемой версии и результатам функциональных испытаний.
Где и как могут проводиться испытания
В лаборатории
Подходит для автономного ПО, контроллеров и комплексов, которые можно предоставить вместе с необходимыми имитаторами и средствами связи.
На стенде заявителя
Используется, если объект связан со специализированной аппаратурой, крупным испытательным стендом или закрытой инфраструктурой.
На месте эксплуатации
Возможно для распределённых систем и объектов, режимы которых нельзя достоверно воспроизвести вне фактической площадки.
С удалённым доступом
Допустимо, когда обеспечены управляемый доступ, идентификация конфигурации, наблюдаемость воздействий и надёжная фиксация результатов.
Для встроенного ПО часто применяется аппаратно-программный или Hardware-in-the-Loop стенд: реальные контроллеры взаимодействуют с имитаторами датчиков, исполнительных устройств и каналов связи. Состав стенда и его пригодность фиксируются в методике и протоколе.
Порядок проведения испытаний
- Предварительное рассмотрение. Анализируются объект, цель, применимый технический регламент, документация и предполагаемый результат.
- Определение границ объекта. Устанавливаются версия, конфигурация, аппаратная платформа, значимые модули и интерфейсы.
- Проверка области аккредитации. Сопоставляются заявленные характеристики, методы и актуальные позиции области RA.RU.21БН02.
- Формирование стоимости и договора. Объём зависит от количества требований, модулей, режимов, стендов и мест проведения работ.
- Разработка или согласование методики. Определяются требования, сценарии, средства испытаний, исходные данные и критерии оценки.
- Подготовка объекта и стенда. Проверяются комплектность, версия, конфигурация, средства связи, имитаторы и условия испытаний.
- Проведение проверок. Выполняются функциональные, идентификационные, интерфейсные, защитные и иные согласованные сценарии.
- Фиксация доказательств. Сохраняются результаты, журналы, контрольные значения, наблюдения и сведения об отклонениях.
- Анализ результатов. Фактические данные сопоставляются с критериями методики; при необходимости выполняются повторные проверки после устранения замечаний.
- Оформление протокола. Указываются объект, версия, условия, методы, результаты и выводы в пределах проведённых испытаний.
- Передача заявителю. Протокол используется в предусмотренной процедуре подтверждения соответствия или приёмки.
Что содержит протокол испытаний
Протокол должен позволять связать проверенный объект с полученными результатами. В общем случае в него включаются:
- наименование заявителя и сведения об испытательной лаборатории;
- наименование программного средства и железнодорожной продукции, в составе которой оно применяется;
- версия, конфигурация, перечень значимых компонентов и идентификационные признаки;
- основания для проведения испытаний и применённые нормативные документы;
- перечень представленной документации;
- условия, место, сроки, стенд и средства испытаний;
- описание выполненных проверок, исходных данных и воздействий;
- фактические результаты, выявленные отклонения и выводы по требованиям;
- ограничения применимости результатов, если они имеются.
Протокол относится к тому объекту и состоянию, которые были идентифицированы во время испытаний. Использовать его для иной сборки, конфигурации или аппаратной платформы можно только после оценки эквивалентности и влияния изменений.
Что делать при изменении версии программного обеспечения
Изменение номера версии не всегда означает существенное изменение функций, но и сохранение прежнего номера не гарантирует неизменность программы. Для оценки важны фактически изменённые файлы, алгоритмы, настройки и интерфейсы.
До распространения ранее полученных результатов на новый релиз рекомендуется подготовить:
- описание изменений и перечень исправленных дефектов;
- сравнение состава модулей и новые контрольные суммы;
- анализ влияния на функции управления, диагностики, защиты и регистрации;
- сведения об изменениях аппаратной и системной платформы;
- результаты регрессионных испытаний;
- обоснование достаточности прежних результатов для неизменившихся частей.
По результатам анализа может быть принято решение о документальном подтверждении неизменности, дополнительных испытаниях затронутых функций или проведении испытаний новой версии в полном объёме.
Чем испытания по техническим регламентам отличаются от сертификации и приёмки ПО
| Процедура | Основная цель | Типичный результат |
|---|---|---|
| Аккредитованные испытания железнодорожного ПО | Получить доказательства соответствия конкретным требованиям регламента, стандарта и документации. | Протокол испытаний для доказательной базы заявителя. |
| Добровольная сертификация ПО | Независимо подтвердить выбранные характеристики программного продукта в СДС ПО СИ. | Методика, протокол, акт, сертификат и приложение при положительном решении органа по сертификации. |
| Приёмочные испытания | Подтвердить выполнение требований договора, ТЗ и критериев приёмки заказчика. | Протокол или акт приёмочных испытаний по согласованной программе. |
| Анализ функциональной безопасности | Подтвердить достижение требований безопасности на уровне системы и жизненного цикла. | Комплекс доказательств, отчётов, верификационных материалов и обоснование безопасности. |
Эти работы могут дополнять друг друга, но не должны подменяться. Состав услуги определяется по цели проекта до разработки методики и заключения договора.
Документы об аккредитации и официальные источники
Для подтверждения компетенции лаборатории на странице размещены файлы области аккредитации, предоставленные в редакции от 8 апреля 2025 года. Актуальный статус и состав области на дату обращения необходимо проверять в реестре аккредитованных лиц и по официальной карточке ФБУ «НИЦ ПМ — Ростест».
Частые вопросы об испытаниях железнодорожного ПО
Какой технический регламент применяется к программному средству?
Это определяется не названием программы, а продукцией, в составе которой она используется, назначением функций и областью соответствующего регламента. Для подвижного состава обычно рассматривают ТР ТС 001/2011, для высокоскоростного транспорта — ТР ТС 002/2011, для объектов инфраструктуры — ТР ТС 003/2011.
Выдаёт ли лаборатория декларацию о соответствии?
Нет. Лаборатория проводит испытания и оформляет протокол. Декларацию принимает заявитель в порядке, установленном применимым техническим регламентом, используя протокол и другие доказательные материалы.
Можно ли испытать только программное обеспечение без всего изделия?
Можно, если объект, требования и необходимая среда испытаний позволяют получить достоверные результаты. Для встроенного ПО нередко требуется контроллер, стенд или доступ к системе, поскольку часть функций проявляется только во взаимодействии с аппаратурой.
Обязательно ли предоставлять исходный код?
Обычно нет. Основные проверки выполняются по документации, исполняемой версии, интерфейсам, тестовым сценариям и фактическим результатам. Код или его фрагменты могут потребоваться, если значимый алгоритм или механизм нельзя подтвердить иным способом.
Можно ли провести испытания удалённо?
Да, когда удалённый доступ обеспечивает контроль конфигурации, воспроизводимость воздействий, наблюдаемость результата и сохранение доказательств. Для стендовых и аппаратно-зависимых функций может потребоваться выезд или предоставление оборудования.
Может ли один протокол распространяться на несколько версий ПО?
Только если все версии однозначно перечислены, различия проанализированы и методика подтверждает достаточность выполненных проверок. Автоматически переносить результаты на последующие релизы нельзя.
Гарантирует ли протокол регистрацию декларации?
Нет. Протокол подтверждает результаты выполненных испытаний в установленном объёме. Полноту доказательной базы, корректность выбора схемы и ответственность за принятие декларации обеспечивает заявитель.
Нужно ли проверять контрольные суммы всех файлов?
Перечень значимых файлов определяется архитектурой и требованиями. В него включают компоненты, изменение которых способно повлиять на заявленные функции, алгоритмы, защиту, обработку или представление данных. Служебные и неизменяемые компоненты могут учитываться иным способом.
Что делать, если ПО обновилось после испытаний?
Следует направить перечень изменений, новые идентификационные сведения и анализ влияния. После рассмотрения определяется, достаточно ли подтверждения неизменности, нужны ли выборочные регрессионные проверки или испытания новой версии.
Как начать испытания программного средства
Для предварительной оценки направьте краткое описание ПО и железнодорожной продукции, в составе которой оно применяется, цель подтверждения соответствия, сведения о версии, перечень применимых требований и имеющуюся техническую и программную документацию.
Специалисты лаборатории определят:
- может ли работа быть выполнена в пределах актуальной области аккредитации;
- какие документы и экземпляры объекта потребуются;
- нужен ли испытательный стенд, оборудование или выезд на площадку;
- какие проверки следует включить в методику;
- какой объём, срок и формат работ целесообразны для заявленной цели.
Телефон: +7 (495) 781-24-50
E-mail: apankov@009lab.ru
Адрес: 119361, Москва, ул. Озёрная, 46, каб. 915.
Материал актуализирован 3 сентября 2026 г..
Направьте назначение, версию и имеющуюся документацию. Специалисты лаборатории определят возможный состав работ, перечень исходных материалов и порядок дальнейшего взаимодействия.
Обсудить задачу