Номер извещения: 0373100040326000016

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Открытый конкурс в электронной форме

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РОСЭЛТОРГ (АО«ЕЭТП»)

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: http://roseltorg.ru

Размещение осуществляет: Заказчик ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ "СИТУАЦИОННО-ИНФОРМАЦИОННЫЙ ЦЕНТР МИНИСТЕРСТВА ТРАНСПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ"

Наименование объекта закупки: На выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы «Портал субсидированных перевозок» (ПСП)

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202603731000403001000017

Номер типовых условий контракта: 1400700000521003

Контактная информация

Размещение осуществляет: Заказчик

Организация, осуществляющая размещение: ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ "СИТУАЦИОННО-ИНФОРМАЦИОННЫЙ ЦЕНТР МИНИСТЕРСТВА ТРАНСПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ"

Почтовый адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1

Место нахождения: 107078, Г.МОСКВА, вн.тер.г. МУНИЦИПАЛЬНЫЙ ОКРУГ КРАСНОСЕЛЬСКИЙ, УЛ САДОВАЯ-СПАССКАЯ, Д. 18, СТР. 1, ПОМЕЩ. 1

Ответственное должностное лицо: Теселкин В. А.

Адрес электронной почты: v.teselkin@sicmt.ru

Номер контактного телефона: 7-495-2490302

Дополнительная информация: Заказчик : Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Юридический адрес: 107078, г. Москва, вн. тер. г. муниципальный округ Красносельский, ул. Садовая-Спасская, д.18 стр. 1, помещ. 1. E-mail: info@sicmt.ru. Телефон: +7(495)2490302. Ответственное должностное лицо Заказчика: Теселкин В.А.

Регион: Москва

Информация о процедуре закупки

Дата и время окончания срока подачи заявок: 18.05.2026 08:00 (МСК)

Дата окончания срока рассмотрения и оценки первых частей заявок: 19.05.2026

Дата проведения процедуры подачи предложений о цене контракта: 20.05.2026

Дата окончания срока рассмотрения и оценки вторых частей заявок: 21.05.2026

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 21.05.2026

Начальная (максимальная) цена контракта

Начальная (максимальная) цена контракта: 149 400 000,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 261770411620577080100100200016201244

Информация о сроках исполнения контракта и источниках финансирования

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 17.12.2026 Сроки исполнения отдельных этапов исполнения контракта определяются на основании заявок заказчика в порядке, предусмотренном контрактом

Количество этапов: 5

Закупка за счет собственных средств организации: Да

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 62.01.11.000 - Этап№1: Техническое проектирование Систем ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система ... 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» ... 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК ... - Условная единица - 1,00 - 14 442 000,00 - 14 442 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система Значение характеристики не может изменяться участником закупки Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» Значение характеристики не может изменяться участником закупки 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Значение характеристики не может изменяться участником закупки 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот 3 Характеристика объектов автоматизации - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» Значение характеристики не может изменяться участником закупки Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; 4 Требования к Системам ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; Значение характеристики не может изменяться участником закупки - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок 5 Состав и содержание работ по развитию АИС УЛСП и ПСП В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ Значение характеристики не может изменяться участником закупки 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 6 Порядок контроля и приемки 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов Значение характеристики не может изменяться участником закупки Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 7 Требования к документированию 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию Значение характеристики не может изменяться участником закупки В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».? - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки - Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок - УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись - API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов - 1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» - 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р - 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) - 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ - 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» - 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» - 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст - 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) - 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом - 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки - 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» - 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот - 3 Характеристика объектов автоматизации - - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» - - Значение характеристики не может изменяться участником закупки - Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП - Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) - Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП - API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан - Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК - Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) - В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости - 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) - Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте - Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов - Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) - В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования - В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» - ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК - 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента - Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы - «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 - Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании - «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий - Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - 4 Требования к Системам - ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - - Значение характеристики не может изменяться участником закупки - - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования - В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения - При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов - технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется - 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем - 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов - 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком - По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования - 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования - 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт - 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL - 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика - 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования - 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД - 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) - 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования - 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 - В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider - Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде - 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком - Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования - 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком - 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком - Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа - Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» - 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем - В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) - 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа - Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 - Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования - 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. - 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования - 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются - 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта - 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем - 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации - ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД - Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей - 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки - Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. - Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки - Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации - 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска - В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков - 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО - В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. - Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. - 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования - Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации - 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» - 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру - Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ - 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования - 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок - 5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки - 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа - 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 - 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 - 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 - 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 - 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 - 6 Порядок контроля и приемки - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - - Значение характеристики не может изменяться участником закупки - Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ - Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП - Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения - 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней - Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП - 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию - Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию - 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии - 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) - 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки - В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию - 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки

Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок

УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись

API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов

1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд»

1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р

8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р)

10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ

14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом»

28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»

35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план)

1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом

1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки

2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению»

2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот

3 Характеристика объектов автоматизации - - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» - - Значение характеристики не может изменяться участником закупки

Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП

Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП)

Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП

API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан

Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК

Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.)

В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости

3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6)

Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте

Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов

Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК

3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03)

В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования

В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий»

ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК

3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента

Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы

«Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4

Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании

«Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий

Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда;

- цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн;

4 Требования к Системам - ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - - Значение характеристики не может изменяться участником закупки

- Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования

В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения

При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов

технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется

4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем

4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника;

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

4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком

По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования

4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт

4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL

4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика

4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования

4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД

4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования

4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2

В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider

Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде

4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

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

Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования

4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком

4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком

Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа

Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных»

4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем

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

4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8)

4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа

Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200

Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования

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

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

4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются

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

4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем

4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации

ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД

Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы;

4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам

– описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей

4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки

Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику.

Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки

Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний

По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком

4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска

В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков

4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО

В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе.

Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования.

4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования

Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации

4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»

4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру

Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком

4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы

АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ

4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования

4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок

5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки

5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа

1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026

2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026

3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026

4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026

5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026

6 Порядок контроля и приемки - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - - Значение характеристики не может изменяться участником закупки

Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ

Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП

Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика

6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней

Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП

6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию

Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию

6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта)

6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию

7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

- 62.01.11.000 - Этап№2: Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система ... 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» ... 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК ... - Условная единица - 1,00 - 30 776 400,00 - 30 776 400,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система Значение характеристики не может изменяться участником закупки Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» Значение характеристики не может изменяться участником закупки 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Значение характеристики не может изменяться участником закупки 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот 3 Характеристика объектов автоматизации На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; Значение характеристики не может изменяться участником закупки - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот 4 Требования к Системам 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы Значение характеристики не может изменяться участником закупки АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком 5 Состав и содержание работ по развитию АИС УЛСП и ПСП В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ Значение характеристики не может изменяться участником закупки 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 6 Порядок контроля и приемки 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов Значение характеристики не может изменяться участником закупки Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 7 Требования к документированию 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию Значение характеристики не может изменяться участником закупки В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».? - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки - Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок - УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись - API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов - 1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» - 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р - 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) - 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ - 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» - 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» - 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст - 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) - 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом - 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки - 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» - 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот - 3 Характеристика объектов автоматизации - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - Значение характеристики не может изменяться участником закупки - - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» - Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП - Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) - Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП - API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан - Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК - Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) - В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости - 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) - Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте - Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов - Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) - В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования - В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» - ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК - 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента - Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы - «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 - Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании - «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий - Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот - 4 Требования к Системам - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - - Значение характеристики не может изменяться участником закупки - АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ - 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования - 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок - ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования - В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения - При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов - технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется - 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем - 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов - 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком - По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования - 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования - 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт - 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL - 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика - 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования - 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД - 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) - 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования - 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 - В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider - Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде - 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком - Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования - 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком - 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком - Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа - Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» - 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем - В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) - 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа - Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 - Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования - 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. - 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования - 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются - 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта - 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем - 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации - ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД - Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей - 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки - Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. - Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки - Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации - 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска - В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков - 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО - В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. - Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. - 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования - Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации - 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» - 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру - Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком - 5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки - 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа - 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 - 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 - 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 - 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 - 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 - 6 Порядок контроля и приемки - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - - Значение характеристики не может изменяться участником закупки - Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ - Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП - Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения - 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней - Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП - 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию - Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию - 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии - 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) - 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки - В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию - 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки

Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок

УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись

API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов

1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд»

1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р

8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р)

10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ

14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом»

28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»

35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план)

1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом

1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки

2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению»

2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот

3 Характеристика объектов автоматизации - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - Значение характеристики не может изменяться участником закупки

- цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн;

- цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП

Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП)

Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП

API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан

Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК

Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.)

В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости

3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6)

Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте

Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов

Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК

3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03)

В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования

В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий»

ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК

3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента

Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы

«Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4

Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании

«Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий

Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

4 Требования к Системам - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - - Значение характеристики не может изменяться участником закупки

АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ

4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования

4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок

ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП;

- Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования

В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения

При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов

технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется

4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем

4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника;

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

4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком

По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования

4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт

4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL

4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика

4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования

4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД

4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования

4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2

В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider

Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде

4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

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

Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования

4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком

4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком

Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа

Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных»

4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем

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

4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8)

4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа

Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200

Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования

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

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

4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются

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

4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем

4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации

ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД

Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы;

4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам

– описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей

4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки

Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику.

Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки

Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний

По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком

4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска

В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков

4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО

В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе.

Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования.

4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования

Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации

4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»

4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру

Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком

5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки

5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа

1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026

2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026

3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026

4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026

5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026

6 Порядок контроля и приемки - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - - Значение характеристики не может изменяться участником закупки

Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ

Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП

Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика

6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней

Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП

6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию

Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию

6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта)

6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию

7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

- 62.01.11.000 - Этап№3: Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система ... 1 Общие сведения 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ ... 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК ... - Условная единица - 1,00 - 48 604 800,00 - 48 604 800,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система Значение характеристики не может изменяться участником закупки Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов 1 Общие сведения 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ Значение характеристики не может изменяться участником закупки 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Значение характеристики не может изменяться участником закупки 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот 3 Характеристика объектов автоматизации 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) Значение характеристики не может изменяться участником закупки В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК 4 Требования к Системам 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем Значение характеристики не может изменяться участником закупки В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» 5 Состав и содержание работ по развитию АИС УЛСП и ПСП В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ Значение характеристики не может изменяться участником закупки 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 6 Порядок контроля и приемки Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ Значение характеристики не может изменяться участником закупки Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов 7 Требования к документированию 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию Значение характеристики не может изменяться участником закупки В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».? - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки - Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок - УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись - API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов - 1 Общие сведения - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ - - Значение характеристики не может изменяться участником закупки - 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» - 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» - 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст - 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) - 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом - 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» - 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р - 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) - 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки - 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» - 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот - 3 Характеристика объектов автоматизации - 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) - - Значение характеристики не может изменяться участником закупки - В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования - В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» - ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК - 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента - Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы - «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 - Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании - «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий - Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» - Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП - Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) - Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП - API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан - Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК - Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) - В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости - 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) - Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте - Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов - Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - 4 Требования к Системам - 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем - - Значение характеристики не может изменяться участником закупки - В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) - 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа - Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 - Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования - 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. - 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования - 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются - 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта - 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем - 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации - ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД - Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей - 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки - Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. - Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки - Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации - 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска - В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков - 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО - В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. - Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. - 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования - Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации - 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» - 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру - Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ - 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования - 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок - ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования - В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения - При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов - технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется - 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем - 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов - 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком - По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования - 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования - 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт - 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL - 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика - 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования - 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД - 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) - 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования - 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 - В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider - Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде - 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком - Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования - 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком - 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком - Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа - Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» - 5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки - 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа - 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 - 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 - 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 - 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 - 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 - 6 Порядок контроля и приемки - Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ - - Значение характеристики не может изменяться участником закупки - Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП - Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения - 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней - Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП - 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию - Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию - 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии - 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) - 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - 7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки - В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию - 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки

Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок

УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись

API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов

1 Общие сведения - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ - - Значение характеристики не может изменяться участником закупки

14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом»

28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»

35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план)

1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом

1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)»

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд»

1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р

8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р)

10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки

2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению»

2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот

3 Характеристика объектов автоматизации - 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) - - Значение характеристики не может изменяться участником закупки

В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования

В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий»

ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК

3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента

Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы

«Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4

Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании

«Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий

Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда;

- цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн;

- цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП

Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП)

Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП

API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан

Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК

Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.)

В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости

3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6)

Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте

Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов

Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК

4 Требования к Системам - 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем - - Значение характеристики не может изменяться участником закупки

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

4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8)

4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа

Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200

Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования

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

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

4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются

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

4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем

4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации

ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД

Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы;

4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам

– описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей

4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки

Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику.

Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки

Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний

По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком

4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска

В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков

4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО

В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе.

Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования.

4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования

Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации

4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»

4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру

Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком

4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы

АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ

4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования

4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок

ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП;

- Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования

В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения

При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов

технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется

4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем

4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника;

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

4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком

По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования

4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт

4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL

4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика

4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования

4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД

4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования

4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2

В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider

Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде

4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

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

Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования

4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком

4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком

Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа

Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных»

5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки

5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа

1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026

2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026

3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026

4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026

5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026

6 Порядок контроля и приемки - Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ - - Значение характеристики не может изменяться участником закупки

Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП

Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика

6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней

Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП

6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию

Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию

6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта)

6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов

7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию

7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

- 62.01.11.000 - Этап№4: Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система ... 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» ... 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК ... - Условная единица - 1,00 - 50 796 000,00 - 50 796 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система Значение характеристики не может изменяться участником закупки Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» Значение характеристики не может изменяться участником закупки 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Значение характеристики не может изменяться участником закупки 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот 3 Характеристика объектов автоматизации «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 Значение характеристики не может изменяться участником закупки Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы 4 Требования к Системам 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД Значение характеристики не может изменяться участником закупки Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) 5 Состав и содержание работ по развитию АИС УЛСП и ПСП В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ Значение характеристики не может изменяться участником закупки 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 6 Порядок контроля и приемки Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП Значение характеристики не может изменяться участником закупки 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней 7 Требования к документированию 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию Значение характеристики не может изменяться участником закупки В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».? - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки - Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок - УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись - API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов - 1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» - 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р - 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) - 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ - 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» - 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» - 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст - 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) - 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом - 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки - 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» - 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот - 3 Характеристика объектов автоматизации - «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 - - Значение характеристики не может изменяться участником закупки - Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании - «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий - Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот - Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) - В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости - 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) - Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте - Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов - Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» - Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП - Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) - Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП - API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан - Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК - 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) - В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования - В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» - ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК - 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента - Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы - 4 Требования к Системам - 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД - - Значение характеристики не может изменяться участником закупки - Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам - АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки - Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах - 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки - Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. - 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска - В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации - 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО - В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. - Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. - 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования - Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации - 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» - 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру - Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ - 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования - 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок - ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования - В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения - При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов - технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется - 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем - 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов - 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком - По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования - 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования - 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт - 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL - 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика - 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования - 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД - 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) - 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования - Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде - 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком - Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа - Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» - 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа - Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 - В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider - 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем - 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации - ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования - 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком - 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком - Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 - Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования - 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. - 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования - 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются - 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта - 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем - В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) - 5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки - 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа - 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 - 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 - 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 - 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 - 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 - 6 Порядок контроля и приемки - Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП - - Значение характеристики не может изменяться участником закупки - 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию - Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию - 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии - 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) - 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ - Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП - Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения - 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней - 7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки - В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию - 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки

Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок

УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись

API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов

1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд»

1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р

8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р)

10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ

14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом»

28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»

35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план)

1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом

1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки

2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению»

2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот

3 Характеристика объектов автоматизации - «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 - - Значение характеристики не может изменяться участником закупки

Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании

«Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий

Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.)

В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости

3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6)

Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте

Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов

Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК

На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда;

- цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн;

- цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП

Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП)

Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП

API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан

Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК

3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03)

В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования

В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий»

ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК

3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента

Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы

4 Требования к Системам - 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД - - Значение характеристики не может изменяться участником закупки

Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам

АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы;

При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей

– описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки

Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах

4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки

Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику.

4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска

В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний

По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком

4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО

В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе.

Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования.

4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования

Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации

4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»

4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру

Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком

4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы

АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ

4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования

4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок

ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП;

- Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования

В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения

При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов

технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется

4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем

4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника;

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

4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком

По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования

4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт

4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL

4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика

4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования

4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД

4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования

Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде

4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

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

Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа

Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных»

4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа

Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2

В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider

4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем

4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации

ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования

4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком

4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком

Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200

Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования

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

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

4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются

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

4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем

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

4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8)

5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки

5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа

1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026

2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026

3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026

4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026

5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026

6 Порядок контроля и приемки - Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП - - Значение характеристики не может изменяться участником закупки

6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию

Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию

6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта)

6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов

Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ

Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП

Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика

6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней

7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию

7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

- 62.01.11.000 - Этап№5: Проведение опытной эксплуатации и приемочных испытаний Систем ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система ... 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» ... 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК ... - Условная единица - 1,00 - 4 780 800,00 - 4 780 800,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система Значение характеристики не может изменяться участником закупки Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов 1 Общие сведения 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» Значение характеристики не может изменяться участником закупки 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2 Цели и назначение развития Систем 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Значение характеристики не может изменяться участником закупки 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот 3 Характеристика объектов автоматизации На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; Значение характеристики не может изменяться участником закупки - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот 4 Требования к Системам 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы Значение характеристики не может изменяться участником закупки АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком 5 Состав и содержание работ по развитию АИС УЛСП и ПСП В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ Значение характеристики не может изменяться участником закупки 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 6 Порядок контроля и приемки 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов Значение характеристики не может изменяться участником закупки Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 7 Требования к документированию 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию Значение характеристики не может изменяться участником закупки В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».? - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки - Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок - УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись - API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов - 1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд» - 1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р - 8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р) - 10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ - 14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом» - 28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств» - 35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст - 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план) - 1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом - 1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки - 2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению» - 2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот - 3 Характеристика объектов автоматизации - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - Значение характеристики не может изменяться участником закупки - - цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн; - - цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» - Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП - Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП) - Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП - API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан - Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК - Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.) - В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости - 3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6) - Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте - Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов - Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - 3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03) - В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования - В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий» - ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК - 3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента - Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы - «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4 - Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании - «Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий - Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот - 4 Требования к Системам - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - - Значение характеристики не может изменяться участником закупки - АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ - 4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования - 4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок - ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП; - - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования - В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения - При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов - технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется - 4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем - 4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника; - - руководство по мониторингу должно содержать: а) перечень метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики способа их сбора; б) перечень метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики способа их сбора; - руководство по восстановлению должно содержать: а) план восстановления отдельных компонентов системы, который составляется из предположения, что отказывает один из компонентов системы, а все остальные компоненты продолжают функционировать б) план восстановления всей системы в целом, который составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию; в) каждый план восстановления должен содержать следующие обязательные параметры: • время восстановления; • пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов - 4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком - По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования - 4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования - 4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт - 4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL - 4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика - 4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования - 4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД - 4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.) - 4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования - 4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2 - В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider - Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде - 4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.1.1 Развитие метода подтверждения ЭВПД с предоставлением сведений по доступным условиям поездки при оформлении проездного документа для осуществления поездки на воздушном и железнодорожном транспорте Развитие текущего метода подтверждения ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте направлено на расширение функциональных возможностей сервиса в части предоставления пассажиру информации о доступных условиях поездки и поддержания актуальных параметров взаимодействия с ИС перевозчиков. Реализация указанной модификации должна быть выполнена путем расширения атрибутивного состава ответа на запрос о подтверждении ЭВПД, включающего, помимо сведений о подтверждении права на льготный проезд, данные о доступных условиях поездки для пассажира. При реализации целевого сервиса требуется учесть возможность повышения пассажиром класса обслуживания за дополнительную оплату собственными средствами разницы стоимости или понижения класса обслуживания, а также типа вагона без взимания за это дополнительных средств. В связи с этим в составе ответа на подтверждение права льготного проезда должны содержаться все доступные классы обслуживания в рамках оформленного ЭВПД и контракта между Минобороны России и Перевозчиком - Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования - 4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком - 4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком - Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа - Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» - 4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем - В режиме регламентного (профилактического) обслуживания Системы могут функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода Систем в данный режим, должен быть определен Подрядчиком. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или ПО, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8) - 4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа - Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200 - Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования - 4.1.5 Требования к надежности функционирования и доступности Показатели надежности Систем должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Системы должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций, таких как: - сбои в системе электроснабжения аппаратной части, приводящие к отключению или перезагрузке сервера, на котором размещены Системы. Восстановление программы должно происходить автоматически после перезапуска сервера и запуска исполняемого файла Системы; - ошибки в работе аппаратных средств (кроме носителей данных и программ). Восстановление функции Систем возлагается на службу администрирования, и политику администрирования Систем; - аварийные ситуации, вызванные неверными действиями пользователей: неверным форматом или недопустимыми значениями входных данных. В указанных случаях Системы должны выдавать пользователю соответствующие сообщения/уведомления, оставаясь в рабочем состоянии или возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. - 4.1.6 Требования по диагностированию Систем Диагностирование АИС УЛСП и ПСП должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности АИС УЛСП и ПСП. В случае внедрения новых диагностических инструментов они должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ. Диагностирование АИС УЛСП и ПСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать установку и настройку мониторинговых инструментов автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО, представляющих собой специализированное ПО, позволяющее эксплуатационным подразделениям производить автоматизированный контроль и диагностирование работы ПО, а также действий, выполняемых пользователями Систем, а также возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. Полный перечень параметров, подлежащих диагностике, определяется на этапе технического проектирования - 4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются - 4.1.8 Требования к эксплуатации и техническому обслуживанию Системы должны функционировать круглосуточно, за исключением периодов проведения регламентных (профилактических) работ, а также устранения возникших нештатных ситуаций. Требования к режимам функционирования Систем описаны в п. 4.1.3. Требования к оказанию услуг по технической поддержке предусматриваются в техническом задании на оказание услуг по технической поддержке в рамках отдельного государственного контракта - 4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - 4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем - 4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации - ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - 4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД - Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - 4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей - 4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки - Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику. - Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки - Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам» - 4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации - 4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска - В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков - 4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО - В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе. - Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования. - 4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования - Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации - 4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» - 4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру - Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком - 5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки - 5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа - 1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026 - 2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026 - 3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026 - 4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026 - 5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026 - 6 Порядок контроля и приемки - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - - Значение характеристики не может изменяться участником закупки - Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ - Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП - Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения - 6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней - Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП - 6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию - Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию - 6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии - 6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта) - 6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки - В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию - 7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение Агент ПОДД Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АК Авиакомпания АРМ Автоматизированное рабочее место АСУ «Экспресс» НП Автоматизированная система управления пассажирскими перевозками «Экспресс» Нового поколения БД База данных ВИС Ведомственная информационная система Витрина данных Комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ ВОСО Центральное управление военных сообщений ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» ДУЛ Документ, удостоверяющий личность ЖД Железнодорожный ИБ Информационная безопасность ИС Информационная система ИС Перевозчиков Информационные системы организаций воздушного или железнодорожного транспорта, осуществляющие перевозки льготных или субсидируемых категорий пассажиров КИИ Критическая информационная инфраструктура Контракт Контракт, в рамках которого исполняется настоящее техническое задание ЛК Личный кабинет Минобороны России Министерство обороны Российской Федерации НСИ Нормативно-справочная информация НСУД Национальная система управления данными НФАП Национальный фонд алгоритмов и программ ОС Операционная система - - Значение характеристики не может изменяться участником закупки

Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» – экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПО Программное обеспечение ПОДД, СМЭВ-4, СМЭВ-3 (ПОДД) Подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещенным на витринах данных ПОИБ Подсистема обеспечения информационной безопасности ПСП Портал субсидированных перевозок РЖД Открытое акционерное общество «Российские железные дороги» Росавиация Федеральное агентство воздушного транспорта СВО Специальная военная операция Российской Федерации Сервис ЭВПД Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД Системы АИС УЛСП и ПСП СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СУБД Система управления базами данных СФР Фонд пенсионного и социального страхования Российской Федерации ТЗ Техническое задание на выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками и портала субсидированных перевозок

УВ Участник взаимодействия – федеральный орган исполнительной власти, государственный внебюджетный фонд и иной орган или организация, участвующие в предоставлении государственных и муниципальных услуг (функций) УВОСО Управление военных сообщений УКЭП Усиленная квалифицированная электронная подпись ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС «Такси» Федеральная государственная информационная система легковых такси – централизованный реестр для учета всех участников рынка таксомоторных перевозок в Российской Федерации ФС Федеральный сегмент ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЭВМ Электронная вычислительная машина – комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. ЭВПД Электронный воинский перевозочный документ ЭДО Электронный документооборот Эксперимент ЭВПД Эксперимент по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам. Проводиться в соответствии с Постановлением Правительства Российской Федерации от 27.03.2026 № 326 ЭЦП Электронная цифровая подпись

API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Blitz Identity Provider Российское программное обеспечение, относящееся к классам IAM, SSO, MFA решений, зарегистрированное в Реестре российского ПО и сертифицированное на соответствие требованиям информационной безопасности ФСТЭК России C4 (нотация) Нотация для описания архитектуры программного обеспечения. Описывает архитектуру системы на четырех уровнях абстракции: контекст, контейнеры, компоненты, код HTTPS HyperText Transfer Protocol Secure – расширение протокола HTTP для поддержки шифрования в целях повышения безопасности IAM Identity and Access Management – сервис идентификации и контроля доступа JSON JavaScript Object Notation – текстовый формат обмена данными, основанный на синтаксисе JavaScript JWT-токен Открытый стандарт для создания токенов доступа, основанный на формате JSON MAX Цифровая платформа MAX Mini-App Мини-приложение – веб-приложение, которое работает внутри мессенджера или социальной сети. Не требует установки, запускается через чат-ботов, инлайн-кнопки или прямые ссылки REST API Representational State Transfer – архитектурный стиль взаимодействия компонентов распределенного приложения в сети SSL Secure Sockets Layer – криптографический протокол TCP Transmission Control Protocol – транспортный протокол, предназначенный для надежной передачи данных между компьютерами в сети TLS Transport Layer Security – криптографический протокол UDP User Datagram Protocol - протокол транспортного уровня, используемый для передачи данных в интернете. В отличие от TCP, UDP ориентирован на скорость передачи и не обеспечивает гарантированную доставку пакетов XML (англ. eXtensible Markup Language) – расширяемый язык разметки. Текстовый язык разметки, основанный на стандартном обобщенном языке разметки (SGML) XSD-схема Язык для описания структуры XML-документов

1 Общие сведения - 1.1 Наименование Систем Полное наименование: Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП. Полное наименование: информационная система «Портал субсидированных перевозок». Условное обозначение: ПСП. В совокупности АИС УЛСП и ПСП именуются как Системы. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками (АИС УЛСП) и информационной системы ««Портал субсидированных перевозок» (ПСП) (далее – Работы). Создание нового сквозного функционала путем доработки двух информационных систем. Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения». Выполнение работ по развитию предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 гг. в составе мероприятия № 103.016 «ПСП и УЛСП» ИТ расхода 103.26.000011 «Развитие Портала субсидируемых перевозок» и ИТ расхода 103.26.000002 «Развитие Автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками (АИС УЛСП)» - - Значение характеристики не может изменяться участником закупки

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1 Подрядчик: определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных муниципальных нужд»

1.3 Основания для выполнения работ 1) Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета от 17.09.2023 № Пр-1855ГС. 2) Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства Российской Федерации от 03.11.2023 № 3097-р. 3) Федеральный закон Российской Федерации от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 4) Федеральный закон Российской Федерации от 10.07.2023 № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 5) Федеральный закон Российской Федерации от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости». 6) Постановление Правительства Российской Федерации от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 7) Решение о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р

8) Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их БД информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555». 9) Распоряжение Правительства Российской Федерации от 30.09.2024 № 2714-р о проведении с 01.10.2024 по 31.12.2025 на территории Российской Федерации эксперимента по использованию сведений о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации, содержащихся в государственной информационной системе «Единая централизованная цифровая платформа в социальной сфере», при предоставлении государственных и муниципальных услуг, услуг государственных и муниципальных учреждений, коммерческих и иных услуг (сервисов) и мер социальной поддержки (в редакции распоряжения Правительства Российский от 23.12.2025 № 3968-р)

10) Постановление Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте» (в редакции постановления Правительства Российской Федерации от 17.06.2025 № 909). 11) Постановление Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1) Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». 2) Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных». 3) Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи». 4) Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». 5) Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». 6) Федеральный закон Российской Федерации от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации». 7) Федеральный закон Российской Федерации от 12.01.1995 № 5-ФЗ «О ветеранах». 8) Федеральный закон от 24.06.2025 № 156-ФЗ «О создании многофункционального сервиса обмена информацией и о внесении изменений в отдельные законодательные акты Российской Федерации». 9) Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 10) Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». 11) Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 12) Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 13) Федеральный закон Российской Федерации «О федеральном бюджете на 2025 год и плановый период 2026 и 2027 годов» от 30.11.2024 № 419-ФЗ

14) «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 15) Федеральный закон Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 16) Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения». 17) Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 18) Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации». 19) Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 20) Постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

21) Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 22) Постановление Правительства РФ от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» 23) Постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин». 24) Постановление Правительства Российской Федерации от 20.04.2000 № 354 «О порядке возмещения расходов, связанных с перевозкой военнослужащих, граждан, уволенных с военной службы и членов их семей, а также их личного имущества». 25) Приказ Министерства внутренних дел Российской Федерации от 22.08.2003 № 667 «О порядке возмещения расходов, связанных с перевозками, а также оформления, использования, хранения и обращения с воинскими перевозочными документами в системе МВД России». 26) Приказ Министра обороны Российской Федерации от 27.12.2017 № 815 «Об определении Порядка, случаев и особенностей оформления, выдачи и использования воинских перевозочных документов, отчетности по ним и организации контроля за их использованием и установлении категорий проезда военнослужащих, граждан, уволенных с военной службы, и членов их семей на железнодорожном, воздушном, водноми автомобильном (за исключением такси) транспорте». 27) Приказ Минтранса России от 05.09.2022 № 352 «Об утверждении Правил перевозок пассажиров, багажа, грузобагажа железнодорожным транспортом»

28) Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 29) Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». 30) Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». 31) Приказ ФСБ России от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации» (Положение ПКЗ-2005) (с изменениями на 12.04.2010). 32) Приказ ФСБ России от 27.12.2011 № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». 33) Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности». 34) Приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»

35) ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст. 36) ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 37) ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 38) ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226- ст. 39) ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 10.11.2026 г. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом выполнения работ (календарным планом) в соответствии с п. 5.1 ТЗ (далее – Календарный план)

1.6 Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

1.7 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом согласно разделу 6 ТЗ и в сроки, установленные разделом 5.1 ТЗ, в соответствии с Календарным планом

1.8 Место выполнения работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

2 Цели и назначение развития Систем - 2.1 Цели развития Систем Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. Обеспечение возможности применения цифровых льгот и субсидий на разных видах транспорта для разных категорий получателей мер социальной поддержки способствует росту транспортной подвижности населения. Недостаточное проникновение цифровых инструментов приобретения билетов и оплаты проезда, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенным на заседании Президиума Государственного Совета по вопросам развития общественного транспорта в стране, которое состоялось 17.08.2023. Целями развития Систем являются: - обеспечение цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - обеспечение вывода в продуктивную эксплуатацию функционала оформления проездного документа с использованием ЭВПД и информационного обмена с системами-источниками ведомств; - создание сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте; - создание сервиса бронирования и оформления проездных документов; - разработка сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК - - Значение характеристики не может изменяться участником закупки

2.2 Назначение Систем АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте, включая возможность доступа к транспортной инфраструктуре и объектам пассажирских обустройств, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социальной поддержки (защиты) на транспорте в безбумажном формате в соответствии с его льготной категорией. ПСП разработан во исполнение постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» и положений постановления Правительства Российской Федерации от 25.12.2021 № 2478 «О внесении изменений в Правила предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению»

2.3 Состав выполняемых задач Для реализации указанных целей развитие Систем должно решать следующие задачи: - реализация возможности цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси; - реализация сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозочным документам; - реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов (далее – Билетный сервис); - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК; Развитие Систем должно быть направлено на достижение следующих эффектов (показателей): - сокращено количество требуемых бумажных документов для подтверждения права для льготного проезда гражданина со статусом «Член многодетной семьи» в легковом такси с 2 до 0; - снижение времени на подтверждение права воинского пассажира на оформление билета путем цифрового подтверждения (в т.ч. посредством Билетного сервиса). - снижение трудозатрат перевозчиков на формирование и согласование отчетности для компенсации выпадающих доходов за перевозку воинских пассажиров по ВПД; - сокращено время на получение информации о наличии федеральных транспортных льгот на железнодорожном или воздушном транспорте для гражданина со статусом «Член многодетной семьи» или «Студент» с 30 до 1 минуты; - возможность повышения мобильности пассажиров за счет обеспечения подтверждения в электронной форме права на оформление субсидированного билета региональной авиакомпании; - снижение временных затрат на проверку отчетности в целях предоставления субсидий региональным авиакомпаниям путем обеспечения перехода на электронный документооборот

3 Характеристика объектов автоматизации - На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: - сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) и региональном уровнях; - информационное взаимодействие с общегосударственными ИС, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи; - предоставление во внешние системы подтверждения наличия у гражданина Российской Федерации права на приобретение авиабилетов по специальным тарифам, согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Решении о порядке предоставления субсидии от 06.03.2026 № 22-68866-00363-Р (ранее – в постановлении Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»); - цифровое подтверждение права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; - обеспечение обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда; - - Значение характеристики не может изменяться участником закупки

- цифровое подтверждение наличия у гражданина права на получение меры социальной поддержки (защиты) регионального уровня, предполагающей возможность приобретения проездного документа по сниженному, льготному или безденежному тарифу путем информационного взаимодействия с ИС выбранных субъектов Российской Федерации; - цифровое подтверждение права пассажира на оформление перевозки железнодорожным транспортом в дальнем и пригородном сообщении по электронному транспортному требованию; - цифровое подтверждение наличия права на приобретение билета по льготному, сниженному или безденежному тарифу на железнодорожный транспорт у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры, подключившего себе электронный студенческий билет; - цифровое подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных данным оформляемого проездного документа с целью реализации возможности цифровизации проезда по ЭВПД (прототип); - цифровое подтверждение сведений о маломобильных группах населения для обеспечения возможности реализации различных сценариев применения, включая подтверждение права на резервирование парковочного места у объекта транспортной инфраструктуры или иного объекта, выполняющего аналогичные функции; - цифровое подтверждение типов пассажира «Инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет в продуктивном контуре; - цифровое подтверждение данных льготных категорий «Участник СВО» и «Член семьи участника СВО» в рамках права на льготу для данных льготных категорий (прототип); - цифровое подтверждение данных льготных категорий «Инвалид» и «Член многодетной семьи» для приобретения льготного билета при пользовании железнодорожным транспортом с применением устройств продаж, функционирующих в режиме офлайн;

- цифровое подтверждение права на резервирование парковочного места у аэропорта или железнодорожного вокзала по государственному регистрационному номеру транспортного средства, управляемого инвалидом или перевозящего инвалида. В соответствии с Актом классификации АИС УЛСП от 07.10.2025 № АК.0710.2025.03: - установлено, что АИС УЛСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе АИС УЛСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) ИС персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

Актом категорирования от 07.10.2025 № АК.0710.2025.04 АИС УЛСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00027.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в АИС УЛСП, и категории значимости. Текущая архитектура АИС УЛСП приведена на рисунке далее (Рисунок 1 – Архитектура АИС УЛСП) Рисунок 1 – Архитектура АИС УЛСП

Архитектурно ПСП построен с использованием следующих подсистем: - «Хранилище данных» – предназначено для централизованного хранения данных, поступающих от АК об операциях с Субсидированными билетами, пассажирах и маршрутах, указанных в билетах, а также справочной информации, обеспечивающей функционирование Системы; - «Платформа мониторинга» – предназначена для автоматизации процессов мониторинга данных об операциях с Субсидированными билетами, поступающих от АК; - «API ПСП» – предназначен для реализации информационного взаимодействия ИС в части приема, обработки запросов и предоставления ответов на запросы; - «Веб-приложение «Личный кабинет» – предназначено для авторизации пользователей Системы в личном кабинете. В зависимости от роли пользователя Личный кабинет обеспечивает выполнение функций сотрудниками Оператора Системы и сотрудниками Росавиации; - «Подсистема информационной безопасности» – обеспечение целостности, конфиденциальности и доступности информации, хранящейся и обрабатываемой в ПСП. Также Система включает ряд сервисов: - сервис ведения журналов; - сервис резервного копирования; - сервис административного управления. Функциональность подсистем и сервисов ПСП представлена в таблице далее (Таблица 4 – Функциональность подсистем и сервисов ПСП)

Таблица 4 – Функциональность подсистем и сервисов ПСП Подсистема/сервис Функциональность «Хранилище данных» Обеспечивает выполнение следующих функций: - хранение данных, полученных от АК; - хранение справочных данных, необходимых для функционирования Системы; - обеспечение целостности данных; - обеспечение доступа к данным; - автоматизированную архивацию данных; - хранение учетных записей пользователей ЛК ПСП; - хранение описаний токенов доступа для пользователей API ПСП - хранения данных по операциям с билетами; - хранение документов отчетности АК по субсидированным перевозкам «Платформа мониторинга» Обеспечивает выполнение следующих функций: - централизованный сбор и хранение журналов (логов) для гибкой обработки данных о процессах работы ПО ПСП и ошибках; - запись метрик работы ПО ПСП в режиме реального времени в БД временных рядов; - доступ к журналам с возможностью осуществления выборки по периоду, событию; - визуализацию метрик работы ПО ПСП; - оповещение о нештатных ситуациях в работе ПО ПСП

API ПСП Обеспечивает методы для обмена данными с системами АК и с АИС УЛСП: - получение баланса квоты субсидированных билетов, который может вызываться в любой момент при процессах взаимодействия АК с пассажиром, таких как, бронирование, оформление, возврат и обмен билета, регистрация пассажира на рейс; - операции с билетами, купленными по специальному тарифу, и представление клиентской системе измененных данных Баланса квоты; - загружаемыми в Систему данными о совершенных операциях с билетами массовым списком в отложенном режиме; - проверки на корректность данных, полученных от ИС АК – должны осуществляться проверки на полноту и ошибки в данных. - взаимодействия с ИС АК для получения данных по перевозкам; - подтверждения права пассажира на приобретение билета по специальному тарифу путем подтверждения личности гражданина, типов пассажира и расчета балансов квот на заданный в запросе период. Подтверждение личности гражданина и типов пассажира производится путем информационного взаимодействия с АИС УЛСП; - безопасной и защищенной передачу данных между ПСП, ИС АК и АИС УЛСП; - возможности оформления билетов по специальному тарифу для отдельных категорий граждан

Веб-приложение «Личный кабинет» Обладает следующими функциональными возможностями: - создание JWT-токена доступа для внешнего приложения с указанием сведений о приложении и срока доступа токена; - получение отчета по субсидированным билетам в разрезе АК; - просмотр статистики по проданным и использованным билетам - поиск операций с билетами по гибкому набору критериев; - поиск операций пассажира по документу, удостоверяющего его личность по гибкому набору критериев; - поиск операций пассажира по номеру перевозочного документа. - управление пользователями ЛК, в части процессов ЭДО; - генерацию доработанных механизмов, реализованных в рамках авторизационных JWT-токенов для АК; - добавление критериев поиска данных об авиаперевозках пассажиров по номеру документа, удостоверяющему личность, или номеру перевозочного документа; - загрузку дополнительных данных для учета в отчетах в Росавиацию; - формирование отчетов по установленной форме от Росавиации («Расчет размера субсидии»; «О количестве фактически перевезенных пассажиров по специальному тарифу»; «О количестве реализованных и забронированных билетов по специальному тарифу»; «Реестр перевозочных документов»); - подписание сформированных отчетов УКЭП; - обеспечение проверки отчетов со стороны Росавиации; - ведение журнала событий ЭДО между АК и Росавиацией; - просмотр и редактирование справочной информации, хранящейся в БД ПСП; - выгрузку отчетов, а также прикрепленным к ним файлов - реализацию личного кабинета для АК

Подсистема обеспечения информационной безопасности Подсистема информационной безопасности обеспечивает целостность, конфиденциальность и доступность информации, хранящейся и обрабатываемой в ПСП Сервис ведения журналов Сервис ведения журналов обеспечивает автоматизацию процессов мониторинга функционирования ПСП Сервис резервного копирования Сервис резервного копирования обеспечивает возможность осуществления резервного копирования данных ПСП и АИС УЛСП при их размещении в одном контуре с ПСП Сервис административного управления Обладает следующими функциональными возможностями: - обеспечение возможности централизованного административного управления ПСП, в том числе установка и обновление системного и прикладного ПО, настройка программных средств и оборудования, проверка их работоспособности, включая просмотр системных журналов и протоколов, контроль производительности, регламентированное и нештатное обслуживание; - мониторинг работоспособности сервисов ПСП; - интерфейсы управления системным программным обеспечением ПСП (ОС, серверами приложений и т. п.)

В соответствии с Актом классификации ПСП от 07.10.2025 № АК.0710.2025.01: - установлено, что ПСП не является государственной информационной системой, но руководствуясь п. 6 приказа ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Требования), принято решение применить Требования для защиты информации, содержащейся в негосударственной системе ПСП, в соответствии с исходными данными и с положениями п. 4 Приложения № 1 «Определение класса защищенности информационной системы» к Требованиям и п. 27 Требований необходимо обеспечить второй класс защищенности (К2); - установлена необходимость обеспечения второго уровня защищенности (УЗ 2) информационных систем персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». - Актом категорирования от 07.10.2025 № АК.0710.2025.02 ПСП присвоена вторая категория значимости объектов КИИ на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Аттестатом соответствия от 05.12.2025 № 3515.00026.2025 подтверждается соответствие требованиям безопасности (защиты) информации в отношении указанных выше класса защищенности, уровня защищенности персональных данных, обрабатываемых в ПСП, и категории значимости

3.3 Развитие объектов автоматизации в рамках настоящего ТЗ Работы по настоящему ТЗ проводятся в отношении подсистем и сервисов Федерального сегмента АИС УЛСП и ПСП. Объектом автоматизации в рамках выполнения работ по настоящему ТЗ являются процессы, направленные на реализацию государственных гарантий, включающих предоставление гражданам транспортных льгот и субсидий, в том числе посредством: - реализации возможности предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализации сервиса цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - создание сервиса бронирования и оформления проездных документов; - реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК. Перечень функциональных подсистем и сервисов федерального сегмента АИС УЛСП и ПСП, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указаны в таблицах далее (Таблица 5, Таблица 6)

Таблица 5 – Перечень функциональных сервисов, модифицируемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготных перевозок по электронным воинским перевозочным документам (прототип) Развитие прототипа сервиса «Электронный воинский перевозочный документ» (ЭВПД) до целевого состояния, обеспечивающего промышленную эксплуатацию сервиса. Реализация сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте

Таблица 6 – Перечень сервисов, разрабатываемых в рамках настоящего ТЗ Сервис Выполняемые работы Сервис льготного проезда члена многодетной семьи в легковом такси Реализация цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Сервис подтверждения права пассажира на перелет по региональной субсидии Реализация сервиса подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК Сервис бронирования и оформления проездных документов Реализация сервиса бронирования и оформления проездных документов

Ключевыми результатами выполнения работ по ТЗ должны являться: - реализованная возможность предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси; - реализованный сервис цифрового подтверждения права на оформление проездных документов по электронным воинским перевозным документам; - реализованный сервис формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа; - реализованный модуль подтверждения права пассажира на перелет на основании финансирования, доводимого по региональной субсидии АК

3.1 Основные сведения об объектах автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу (контракт от 03.07.2023 № ОК/23_03)

В 2024 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части подготовки к миграции АИС УЛСП на ЕЦП «ГосТех» (контракт от 24.05.2024 № ОК/24_03), реализации автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область, обеспечения информационного взаимодействия с ИС, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня, ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации, государственной информационной системой «Единая централизованная цифровая платформа в социальной сфере» с целью обеспечения обмена данными по мерам социальной поддержки (защиты) разных уровней (федеральные, региональные), ИС, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования

В 2025 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части расширения типов льгот и субсидий, категорий пассажиров-получателей мер социальной поддержки, видов перевозочных документов, перевозчиков, систем-источников, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками, обеспечение подтверждения права пассажира-инвалида на льготную парковку в объектах транспортной инфраструктуры, перевод системы авторизации Системы на внешние сертифицированные средства защиты информации. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий»

ПСП создана в рамках контракта № 0373100040322000013 от 17.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 17704116205 22 000014) для исполнения постановления Правительства Российской Федерации от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» в части обеспечения корректного расчета балансов квот пассажиров по предоставленным АК данным по операциям с билетами по специальным тарифам, а также предоставления рассчитанных балансов квот пассажиров по запросам АК

3.2 Текущее состояние объектов автоматизации АИС УЛСП состоит из двух сегментов: федерального и регионального. Федеральный сегмент реализован в единственном числе. Региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости. Перечень функциональных подсистем и сервисов федерального сегмента показан в таблицах далее (Таблица 1 и Таблица 2). Таблица 1 – Перечень функциональных подсистем федерального сегмента

Функциональная подсистема Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот – иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. Формирование и хранение реестра данных льготных категорий «Инвалид» и «Члены многодетных семей» для последующего обеспечения возможности их получения ИС перевозчиков. Хранение сведений об электронных воинских перевозочных документах и проездных документах, оформленных с использованием ЭВПД «Администрирование» Управление учетными записями пользователей АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи (ролевая модель). Управление таксономией льгот, включая блок НСИ по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. Обеспечение применения внешних сертифицированных на соответствие требованиям информационной безопасности ФСТЭК России средств управления доступом (Blitz Identity Provider) «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы

«Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.). Обеспечение возможности цифрового подтверждения льготных категорий «Инвалид» и «Члены многодетных семей» с применением устройств продаж, функционирующих при нестабильном или отсутствующем интернет-соединении. Обеспечение устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, в рамках общего процесса подтверждения льготной категории/типа пассажира. Обеспечение возможности цифрового подтверждения типов пассажира «Инвалид 1 группы», «Инвалид 2 группы», «Инвалид 3 группы» и «Ребенок-инвалид» в рамках процесса автоматизированного цифрового подтверждения права пассажира на субсидированный авиабилет посредством витрины НСУД СФР в продуктивном контуре СМЭВ-4

Таблица 2 – Перечень функциональных сервисов федерального сегмента Сервис Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта Российской Федерации, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом, а также обеспечения возможности цифрового подтверждения сведений о маломобильных группах населения в рамках различных сценариев применения, включая подтверждение права на резервирование парковочного места в объектах транспортной инфраструктуры «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечение возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании

«Сервис льготных перевозок обучающихся граждан Российской Федерации с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. «Сервис взаимодействия с цифровыми платежными инструментами, включая сервисы виртуальных социальных карт» Обмен данными с ИС перевозчиков, включая перевозчиков железнодорожного транспорта пригородного сообщения, и участников рынка пассажирских перевозок, обеспечивающих реализацию технологии бесконтактной оплаты проезда с использованием данных геолокации для идентификации, аутентификации и валидации в процессе оплаты проезда, с целью предоставления возможности применения технологии безинфраструктурной валидации открытого контура для пассажиров льготных категорий с использованием систем глобального позиционирования и геолокации «Сервис льготных перевозок по электронным воинским перевозочным документам (прототип)» Подтверждение наличия электронного воинского перевозочного документа, а также соответствия его данных - данным оформляемого проездного документа в рамках реализации возможности цифровизации проезда по ЭВПД. Трехсторонний обмен данными по оформленным перевозочным документам между ведомственными ИС – АИС УЛСП – ИС перевозчиков воздушного и железнодорожного транспорта и системами-интеграторами. Получение от систем-потребителей данных о поездках, совершенных по ЭВПД, для формирования безбумажной отчетности по специальным перевозкам «Сервис подтверждения льгот участникам СВО (прототип)» Подтверждение наличия льготной категории «Участник СВО» и «Член семьи участника СВО» для последующей передачи в системы продаж перевозчика в рамках обеспечения возможности цифрового подтверждения права на льготу для данных льготных категорий

Перечень функциональных подсистем регионального сегмента представлен в таблице далее (Таблица 3). Таблица 3 – Перечень функциональных подсистем регионального сегмента Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной или субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах – иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учетными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учетных записей, в том числе в части ограничения информации, доступной той или иной учетной записи. Управление составом и содержанием справочников и классификаторов «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платежных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

4 Требования к Системам - 4.1.16 Требования к персоналу Численность персонала Систем должна определяться с учетом следующих требований: - структура Систем должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности; - системное и прикладное ПО Систем должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП и ПСП утверждается штатным расписанием Оператора АИС УЛСП и ПСП. Численность персонала АИС УЛСП и ПСП должны уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы - - Значение характеристики не может изменяться участником закупки

АИС УЛСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Системный администратор – доступ на уровне системного и прикладного ПО без непосредственного доступа к интерфейсу ЛК Региона и АИС УЛСП; - Оператор СИЦ – доступ к интерфейсу ЛК Региона без ограничения информации по конкретному региону; - Оператор региона – доступ к интерфейсу ЛК Региона с ограничением информации по конкретному региону; - Администратор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования/блокировки/разблокировки, а также согласования записей для всех разделов и справочников, где данная функциональность предусмотрена; - Оператор федерального сегмента – доступ к интерфейсу ФС АИС УЛСП с возможностью просмотра/заведения/редактирования ограниченного набора данных. Внесение изменений в таксономию льгот и субсидий требует согласования Администратора Сегмента; - Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ

4.2.6.5 Функциональные требования к панели управления и администрированию Билетного сервиса Панель управления Билетного сервиса должна обеспечивать возможность просмотра информации о бронированиях, совершенных с использованием Билетного сервиса, а также управления возможностью оформления билетов с взиманием платы с пассажиров. Должно быть обеспечено отображение следующих сведений о бронировании: - идентификатор бронирования; - статус бронирования; - маршрут перевозки; - сведения о пассажирах; - сведения о выбранных тарифах; - сведения о дополнительных услугах; - дата и время создания бронирования; - дата и время возврата билетов. Панель управления должна обеспечивать возможность поиска бронирований по следующим параметрам: - номер бронирования; - номер перевозочного документа. Панель управления должна обеспечивать возможность фильтрации бронирований по следующим параметрам: - дата и время создания бронирования; - дата и время вылета/отправления; - статус бронирования; - перевозчик; - маршрут перевозки. Состав отображаемых сведений может быть уточнен на этапе технического проектирования. Должна быть доработана ролевая модель Систем в части создания новых ролей с назначением доступа к разрабатываемым функциям Билетного сервиса. Состав ролей может быть уточнен на этапе технического проектирования. Панель управления должна обеспечивать логирование операций бронирования. Логированию должны подлежать операции, включая: - создание бронирования (отправка запросов/получение ответов на создание бронирования во внешние ИС); - выполнение операций возврата; - получение перевозочных документов. По каждой операции должна быть обеспечена регистрация следующих сведений: - тип операции; - дата и время операции (дата и время отправки запроса/дата и время получения ответа); - результат операции (в том числе – ошибки взаимодействия с ИС). Состав сведений может быть уточнен на этапе технического проектирования

4.2.6.6 Требования к реализации модуля подтверждения права пассажира на перелет на основании регионального субсидирования Региональное субсидирование предназначено для возмещения затрат на перевозку пассажиров по субсидированным маршрутам в регионах Российской Федерации (региональным, межрегиональным) из федерального и/или регионального бюджета. Сервис предназначен для хранения сведений об условиях предоставления и учета субсидий для авиаперевозчиков и пассажиров в соответствии с федеральными/региональными нормативно-правовыми актами. Назначением работ является предоставление организациям воздушного транспорта Сервиса региональных авиаперевозок, который включает: - цифровое подтверждения права пассажиров на покупку авиабилета по специальному региональному тарифу, включающее следующую функциональность: а) предоставление в цифровом формате актуальных персонифицированных данных по принадлежности пассажира к определенному типу, дающему право на оформление билета по специальному тарифу согласно региональным нормативно-правовым актам; б) расчет балансов квот, количественно ограничивающих приобретение пассажирами билетов по специальному тарифу согласно нормативно-правовым актам регионов; в) ведение цифрового учета оснований применения льгот регионального уровня в отношении пассажиров и ведение отчетности о выполнении региональных субсидированных перевозок; - учет региональных субсидированных перевозок, включающий следующую функциональность: а) контроль субсидированных маршрутов, включая условия софинансирования регионов; б) обеспечение учета региональных субсидированных перевозок согласно утвержденному перечню маршрутов; в) формирование отчетности для получения субсидий; г) хранение информации об НПА региональных субсидированных перевозок

ПСП спроектирована и реализована с учетом ее эксплуатации функциональными группами пользователей: - Администратор ПСП – установка и настройка параметров ПО; - Оператор системы. В обязанности Оператора системы входят: а) заключение соглашений с АК об информационном взаимодействии; б) создание JWT-токенов доступа; в) создание пользователей ЛК ПСП; г) контроль за своевременным обновлением данных пользователей ЛК ПСП, имеющих право на подписание документов ЭЦП; д) просмотр информации по билетам по данным документа, удостоверяющего личность пассажира или номеру билета при осуществлении разбирательств с пассажирами; - Проверяющий. В обязанности проверяющего входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) внесение комментариев к отчетам по найденным замечаниям; - Согласователь. В обязанности согласователя входят: а) проверка ежемесячных отчетов АК в рамках своих должностных компетенций; б) согласование/отклонение отчетов с указанием причины отклонения; в) внесение комментариев к отчетам по найденным замечаниям; г) формирования решения на выплату или служебной записки на отказ; д) контроль выплаты по утвержденным отчетам; - Утверждающий. В обязанности утверждающего входит подписание ЭЦП решений на выплату или служебной записки на отказ; - Сотрудник АК. В обязанности утверждающего входят: а) формирование и отправка запросов на получение, данных по подтверждению личности и типов пассажира, а также балансам квот в случае оформления билета по квотируемому субсидированному направлению; б) добавление и изменение данных по оформленным, возвращенным, обменянным и использованным билетам; в) добавление дополнительных данных по учету в отчетах; г) формирование отчетов в Росавиацию согласно договору между АК и Росавиацией с подписанием ЭЦП; д) корректировка отклоненных отчетов Росавиацией с повторным подписанием ЭЦП;

- Администратор ИБ – настройка средств защиты от несанкционированного доступа, средств межсетевого экранирования, антивирусной защиты, контроль их работы, обновление баз вредоносных программ, диагностику и устранение неисправностей или сбоев, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, настройка средств контроля защищенности информации, контроль их работы, обновление баз уязвимостей, а также осуществляет контроль выполнения требований и организационных мероприятий по защите информации в рамках системы защиты информации, выявление инцидентов информационной безопасности и реагирование на них; - Администратор СКЗИ – настройка средств криптографической защиты информации, контроль их работы, диагностику и устранение неисправностей или сбоев, ведение поэкземплярного учета СКЗИ, а также осуществление контроля за соблюдением условий использования СКЗИ. Пользователи «Администратор ИБ» и «Администратор СКЗИ» являются пользователями ПОИБ, модифицируемой в рамках отдельного государственного контракта. Перечень ролей и их ролевые возможности могут быть скорректированы на этапе технического проектирования

В рамках работ по реализации Сервиса региональных авиаперевозок подрядчиком должен быть проведен анализ федеральных и региональных НПА с целью установления: - информации о специальных тарифах на перевозку пассажиров в регионах Российской Федерации; - правил предоставления субсидий авиаперевозчикам в регионах Российской Федерации; - предоставления льготного проезда воздушным транспортом на региональные маршруты в регионах Российской Федерации, льготные категории пассажиров; - правил формирования и предоставления отчетности перевозчиком для возмещения затрат; - информации о специальных тарифах на маршрут, количество предоставленных мест на маршрут. Анализ федеральных и региональных НПА, регулирующих порядок организации перевозок воздушным транспортом, должен быть проведен Подрядчиком на основе данных, содержащихся в открытых источниках. Результаты анализа НПА должны быть предоставлены Подрядчиком в адрес Заказчика в виде аналитической записки. Согласование результатов проведенного анализа с АК выполняется Заказчиком. Сервис региональных авиаперевозок должен предоставлять следующую функциональность для региональных авиаперевозок: - подтверждение региональной льготной категории пассажира; - учет балансов квот на региональные субсидированные авиаперевозки; - учет операций с билетами; - агрегирование данных по субсидированным региональным авиаперевозкам, для формирования отчетности организациям воздушного транспорта. Порядок формирования данных о региональных льготных категориях пассажиров должен быть определен в соответствии с региональными НПА на этапе технического проектирования. Для определенных на этапе технического проектирования льготных категорий пассажира должно быть обеспечено взаимодействие с соответствующими витринами данных или ИС, содержащими необходимые для подтверждения сведения

При наличии в регионе ограничений по количеству субсидированных перевозок на пассажира, учет баланса квот должен учитывать баланс по всем категориям квотирования согласно региональным НПА. При этом, расчет баланса квот на категорию квотирования должен учитывать: - количество доступных единиц квотирования; - количество оформленных единиц квотирования; - количество возвращенных единиц квотирования; - количество использованных единиц квотирования. Учет операций с билетами должен производиться по следующим данным: - данные билетов; - данные о пассажире и его типе; - данные об АК; - данные о тарифах и признак специального тарифа. Полный список сведений об операциях с купонами билетами должен быть определен на этапе технического проектирования. Процесс агрегирования данных по субсидированным региональным авиаперевозкам должен производиться по следующим сведениям: - данные по учету билетов; - сведения по изменениям в билетах; - данные по перевозкам по маршрутам. Детальный состав агрегированных данных должен быть определен на этапе технического проектирования. Обмен данными между компонентами целевого сервиса и внешними системами должен осуществляться в автоматическом режиме и обеспечивать валидацию входящей и исходящей информации. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ, а также предусматривать возможность адаптации целевого сервиса к требованиям СМЭВ-4 при переходе на новый стандарт без изменения логики процессов

технического проектирования. 4.1.17 Требования к квалификации персонала Систем, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере к системным администраторам предъявляются следующие требования: - знание основных принципов построения систем управления БД; - наличие расширенных знаний в области поддержки пользователей; - знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации. Специальные квалификационные требования к группам пользователей «Оператор СИЦ», «Оператор региона», «Администратор федерального сегмента», «Оператор федерального сегмента» не предъявляются, «Администратор ПСП», «Оператор системы», «Проверяющий», «Согласователь», «Сотрудник АК». Специальные квалификационные требования к группам пользователей «Администратор ИБ» и «Администратор СКЗИ» предъявляются в рамках ТЗ на ПОИБ, модифицируемой в рамках отдельного государственного контракта. 4.1.18 Требования к эргономике и технической эстетике Требований к эргономике и технической эстетике не предъявляется

4.2 Функциональные требования к развитию Систем 4.2.1 Требования к оптимизации функциональности при реализации развития информационных Систем В целях управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для взаимодействия с перевозчиками, расчета балансов квот пассажиров, формирования реестров перевозок и отчетности по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. В рамках технического проектирования требуется: - провести анализ сквозных процессов с целью их последующей оптимизацией, в том числе с возможностью рефакторинга существующей реализации программного обеспечения; - обеспечить возможность работы с единым массивом данных и сущностей, распределенных между различными учетными системами; - предусмотреть единый механизм доступа, отображения и управления типами данных; - предусмотреть унифицированные правила доступа к распределенным функциям Систем. Результат должен быть представлен по итогам завершения проектирования систем

4.3. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Систем в действие 4.3.1 Требования к документации Состав документации, разрабатываемой в рамках настоящего ТЗ, указан в столбце «Результат» календарного плана работ (п. 5.1). Дополнительно для ряда документов предъявляются следующие требования: - схема сетевого взаимодействия должна содержать информацию с указанием: а) портов, используемых для установления сетевых соединений; б) протокола соединения (TCP/UDP); в) направления трафика между компонентами системы; - инструкция по установке должна содержать: а) пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; б) исчерпывающий перечень команд для первичной настройки системы; в) следующий дополнительный объем информации: • перечень пакетов, необходимых для работы решения, с указанием их версий; • перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; • код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; • перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника;

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

4.2.2 Требования к реализации цифрового подтверждения права пассажира со статусом «Член многодетной семьи» для льготного проезда в легковом такси Интеграция с ИС служб заказа легкового такси (далее – Агрегатор) производится для предоставления возможности пассажиру со статусом «Член многодетной семьи» получения льготного проезда в легковом такси. Для обеспечения информационного обмена между ИС служб заказа легкового такси (далее – Агрегатор) и ПСП должен быть реализован сервис по стандарту REST API. Для подтверждения данных пассажира и его льготного статуса должен осуществлять обмен данными с АИС УЛСП. Для реализации предоставления пассажиру со статусом «Член многодетной семьи» льготного проезда в легковом такси Подрядчиком должно быть реализовано: - получение сведений о пассажире легкового такси от ИС Агрегатора с целью подтверждения наличия у пассажира действующего статуса «Член многодетной семьи», включающих данные: а) СНИЛС; б) дату рождения; - формирование и передача ответа о наличии у пассажира, действующего на момент запроса статуса «Член многодетной семьи»; - получение сведений о фактах поездки с использованием льготного статуса от ИС Агрегатора и формирование соответствующей отчетности. Техническое решение должно быть реализовано с возможностью модификации для расширения номенклатуры видов и типов льготных категорий. Состав передаваемых и получаемых данных может быть изменен и/или дополнен на этапе технического проектирования по согласованию с Заказчиком

По согласованию с Заказчиком запрос сведений о статусе «Член многодетной семьи» может производиться посредством внутреннего реестра многодетных или получением данных посредством СМЭВ. Также Заказчиком на этапе технического проектирования вышеуказанное описание интеграции может быть дополнено взаимодействием АИС УЛСП с ФГИС «Такси», обеспечивающей сбор, обработку, систематизацию и хранение реестров служб легкового такси. Окончательное решение о необходимости интеграции, а также ее архитектурные и функциональные характеристики будут определены в рамках этапа технического проектирования

4.2.2.1 Требования к формированию и отображению сведений об использовании данных запросов от ИС Агрегатора по членам многодетных семей Необходимо обеспечить формирование и отображение информации по запросам на цифровые подтверждения льготного статуса и о фактах использования от ИС Агрегатора в пользовательском интерфейсе. Сведения по запросам от ИС Агрегатора по членам многодетных семей должны быть представлены в графическом виде и формироваться на основании следующих данных: - количество запросов; - результат обработки запросов. Требования к визуальным элементам: - столбчатый график должен демонстрировать количество отработанных запросов по месяцам, где ось x – время по месяцам, ось y – количество запросов, типу пассажира, системе-потребителю; - столбчатый график должен демонстрировать количество запросов по типу льгот, где ось x – время по месяцам, ось y – количество запросов с подтвержденным и не подтвержденным типом льгот, типу пассажира, системе-потребителю. По согласованию с Заказчиком формат, способ получения данных для формирования статистики и способ отображения данных может быть изменен на этапе технического проектирования. Требования к составу данных и их отображению должны быть согласованы с Заказчиком на этапе технического проектирования

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и ОС, применяемыми в инфраструктуре Заказчика. 2) Решение должно работать в изолированной сети (без доступа к информационно-телекоммуникационной сети «Интернет»). 3) Допускается использование только кластеризованных БД: должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика. 4) Решение должно быть отказоустойчивым: а) отказоустойчивость решения реализуется самим решением или на уровне отдельных его компонентов; б) использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо. 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. 6) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy). 7) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity & Access Management, IAM), которая должна обеспечиваться посредством Blitz Identity Provider. 8) Контейнеры должны разворачиваться на Kubernetes-платформе Deckhouse». 9) Разворачивание контейнеров должно производиться с использованием helm chart версии 3: а) не допускается использование нескольких helm chart для разворачивания одного решения; б) допускается использование «зонтичного» helm chart (helm chart, который запускает другие helm chart); в) запрещается использование любого метода кодирования в файлах helm chart. 10) В момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика, Заказчику должны быть переданы следующие артефакты: а) пакеты, требуемые для работы решения; б) исходный код решения; в) контейнеры, требуемые для работы решения. 11) Подрядчик не имеет доступа в продуктивный контур Заказчика: запрещается передача данных из тестового контура в продукт

4.3.3 Требования к защищенным соединениям 1) Решение должно содержать запрет на применение протокола HTTP в явном виде. 2) При подключении к решению с использованием протокола HTTP должно происходить перенаправление на HTTPS. 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже. 4) Решение должно содержать явный запрет на применение всех версий протокола SSL

4.2.3 Требования к интеграции с витринами данных Необходимо выполнить развитие существующего сервиса интеграций с витринами данных с целью подтверждения мер социальной поддержки пассажира и их привязки к различным видам уникальных идентификаторов. Для получения набора сведений по мерам социальной поддержки требуется: - интеграция с внешними информационными системами для получения сведений о региональных мерах поддержки с учетом специфики транспортной отрасли; - разработка механизма присваивания сквозной информации о мерах социальной поддержки к уникальному идентификатору; - организация витрины данных для публикации информации. Требования к набору витрин данных и составу сведений должны быть согласованы Заказчиком на этапе технического проектирования. Организация взаимодействия для интеграции АИС УЛСП с витринами данных относится к зоне ответственности Заказчика

4.2.3.1. Требования к конфигуратору мер социальной поддержки Требуется выполнить доработку по развитию конфигуратора мер социальной поддержки в рамках функционала Систем в части хранения и управления мерами социальной поддержки, механиками расчета тарифов, маршрутов и их привязки к типам и видам перевозок (дальнего, пригородного, городского сообщения) из интерфейса личного кабинета АИС УЛСП/через программные интерфейсы взаимодействия. Требования к вариантам развития конфигурации мер социальной поддержки должны быть согласованы с Заказчиком на этапе технического проектирования

4.2.4 Требования к реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД В рамках настоящего ТЗ необходимо доработать прототип сервиса «Электронный воинский перевозочный документ» до целевого состояния, готового к промышленной эксплуатации и обеспечивающего бесперебойное межведомственное информационное взаимодействие. Сервис цифрового подтверждения права на оформление проездных документов по ЭВПД должен обеспечивать выполнение следующих функций: ? получение данных ЭВПД из ИС Минобороны России посредством СМЭВ; ? обработка и хранение данных ЭВПД; ? прием и обработка электронного запроса на подтверждение права на проезд без взимания платы с пассажира из ИС организации железнодорожного или воздушного транспорта при соблюдении условий отсутствия в передаваемых данных указания на ведомственную принадлежность пассажира; ? сопоставление данных ЭВПД, поступивших от ИС Минобороны России с данными запроса, поступившего из ИС организации железнодорожного или воздушного транспорта, на основании заданных критериев, а также реализация функционала передачи ответа (полного подтверждения данных, отрицательного результата с информацией о данных, в которых обнаружены расхождения, а также отрицательного результата проверки (данные не обнаружены) в информационную систему организации железнодорожного или воздушного транспорта; ? получение и обработка ответов из ИС организаций железнодорожного или воздушного транспорта по результатам оформления билета; ? получение данных билета, оформленного ИС организации железнодорожного или воздушного транспорта на основании положительного ответа, с сохранением данных билета в связке с номером ЭВПД в подсистеме отчетности; ? получение данных о статусе билета и (или) типе совершенной операции из ИС организации железнодорожного и (или) воздушного транспорта, его обработка и сохранение; ? передача данных о статусе ЭВПД в ИС Минобороны России после регистрации данных, оформленного по этому ЭВПД

4.3.4 Требования к контейнерам, разворачиваемым на базе Kubernetes-платформы Deckhouse 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025. 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено. 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.). 4) Каждый контейнер должен содержать следующие конфигурационные параметры: а) securityContext.readOnlyRootFilesystem: true; б) securityContext.runAsNonRoot: true. 5) Каждый контейнер должен писать логи в stdout: а) допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки); б) допускается запись логов в формате json; в) запрещается совмещение формата записи логов в рамках одного контейнера. 6) Каждый pod должен быть снабжен network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные. 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap. 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret. 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера. 10) Каждый контейнер должен содержать в себе liveliness и readiness probes: контейнер должен выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes. 11) В контейнере не может запускаться более одного процесса. 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.3.5 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом: покрытие кода unit-тестами должно быть не менее 95%. Требования к покрытию кода unit-тестами могут быть уточнены на этапе технического проектирования. 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования: а) нагрузочное тестирование должно включать в себя тестирование производительности, надежности и стресс-тестирование; б) перед проведением нагрузочного тестирования Подрядчик должен предоставить Заказчику план проведения нагрузочного тестирования; в) показатели нагрузочного тестирования в части количества запросов в секунду должны основываться на показателях производительности системы, а результат – на показателях времени отклика, указанных в п. 4.1.4 настоящего ТЗ. 3) Подрядчик должен предоставить тестовые данные для проведения функционального тестирования

4.1 Требования к развитию Систем в целом В настоящее время с целью управления процессом льготных и субсидированных перевозок реализованы две ИС: - ПСП – для расчета балансов квот пассажиров, а также формирования реестров перевозок и статистики по операциям с субсидированными билетами; - АИС УЛСП – для обеспечения возможности централизованного получения, обработки, хранения и передачи в системы-потребители информации в цифровом формате о доступных гражданину мерах социальной поддержки и государственной социальной помощи на транспорте. АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте, согласно действующей нормативно-правовой базе, в том числе при межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р в части создания «единого сервиса предоставления льгот и субсидий». ПСП обеспечивает исполнение постановления Правительства Российской Федерации от 13.12.2024 № 1776 «О проведении эксперимента по автоматизации процесса управления льготными и субсидированными пассажирскими перевозками на воздушном транспорте». Текущее состояние Систем указано в п. 3.2

В рамках выполнения Работ по настоящему ТЗ автоматизации/цифровизации подлежат процессы подтверждения льготных категорий, обеспечения устойчивого информационного обмена с организациями железнодорожного транспорта и авиаперевозчиками, подтверждение права пассажира на перелет на основании регионального субсидирования, подтверждение льготных категорий при проезде в такси, а также MAX, формирования безбумажной отчетности по воинским перевозкам на железнодорожном и воздушном транспорте. В целях повышения эффективности сквозных бизнес-процессов должна быть выполнена консолидация ИС контура транспортных льгот и субсидий (АИС УЛСП и ПСП). Системы должны функционировать на имеющемся аппаратном и программном обеспечении, предоставленным Заказчиком. В рамках выполнения Работ необходимо расширить функциональные возможности Систем, обеспечить развитие действующих компонентов, а также создать новые. Перечень функциональных подсистем и сервисов, разрабатываемых и модифицируемых в рамках настоящего ТЗ, указан в п.3.3 (см. Таблицу 5, Таблицу 6). Аутентификация и авторизация пользователей интерфейса Систем должны вестись посредством решения Blitz Identity Provider

Для реализации сервиса цифрового подтверждения права на оформление проездных документов по ЭВПД требуется выполнить работы: - развитие методов взаимодействия с ИС Перевозчиков (п. 4.2.4.1); - интеграцию в продуктивном контуре СМЭВ с ИС Минобороны России (п. 4.2.4.2); - организацию межсистемной синхронизации НСИ между всеми участниками информационного взаимодействия (п. 4.2.4.3). Передача данных должна производиться с использованием унифицированных форматов XML/JSON в соответствии с интеграционными профилями участников информационного взаимодействия. Архитектура обмена данными должна предусматривать масштабируемость и возможность расширения атрибутивного состава передаваемых данных. Ранее разработанный прототип сервиса ЭВПД реализовывал базовый функционал подтверждения ЭВПД в ограниченном тестовом контуре, без регламентированных межведомственных процедур и интеграций. Промышленная версия сервиса должна обеспечить переход с тестовых шлюзов прототипа на регламентированные каналы взаимодействия, функционирующие в промышленной среде

4.2.4.1 Требования к развитию методов взаимодействия с внешними системами продаж Перевозчиков Существующее взаимодействие с ИС Перевозчиков на железнодорожном и воздушном транспорте должно быть модифицировано для реализации информационного обмена через единый шлюз (систему-интегратор), в качестве которого для ЭВПД Минобороны России должен выступать ПСП, обеспечивающий возможность взаимодействия с ИС Перевозчиков и их системами продаж. Для обеспечения данного взаимодействия в АИС УЛСП должен быть реализован интерфейс (REST API) для ПСП, использующий унифицированный JSON-формат для запросов на подтверждение права льготного проезда для перевозчиков железнодорожным и воздушным транспортом. Обмен данными между сервисом ЭВПД и ИС перевозчиков должен осуществляться в автоматическом режиме. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

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

Взаимодействие с внешними системами-источниками должно вестись: - посредством СМЭВ-4 для систем-источников среды СМЭВ, реализованных в формате витрины данных НСУД; - посредством СМЭВ-3 для систем-источников среды СМЭВ, реализованных для взаимодействия посредством видов сведений; - посредством REST API (с обеспечением защищенного канала связи) в случае, если система-источник функционирует вне среды СМЭВ. Взаимодействие с внешними системами-потребителями должно вестись: - посредством REST API (с обеспечением защищенного канала связи); - посредством файлового обмена. Требования к обеспечению защищенного канала должно осуществляться в соответствии с приказом ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных» (предоставляется Заказчиком по запросу). Требования к взаимодействию с внешними ИС и передаваемой в рамках данного взаимодействия в АИС УЛСП информации должны быть согласованы с обладателями данной информации. Для выполнения указанного требования Подрядчик должен сформировать запрос, который направляется Заказчиком обладателю информации. Полученные итоговые данные Заказчик передает Подрядчику для учета при выполнении работ по контракту. Применяемое в системе ПО, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации». Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на этапе технического проектирования

4.1.1 Требования к технологической архитектуре Архитектура АИС УЛСП при развитии должна быть сохранена и включать в себя следующие функциональные подсистемы: - «Хранилище данных»; - «Администрирование»; - «Визуализация данных»; - «Информационный обмен». Должна быть обеспечена возможность взаимодействия подсистем друг с другом для беспечения сквозной передачи данных. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком

4.1.2 Требования к интеграционной архитектуре Решения по взаимодействию смежных и внешних ИС с АИС УЛСП и ПСП в части идентификации и аутентификации должны быть совместимы с применением решения Blitz Identity Provider. Подключение внешних и смежных ИС к АИС УЛСП и ПСП должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» посредством построения защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Подключение внешних АРМ должно осуществляться в соответствии с техническими условиями (Приказ ФГБУ «СИЦ Минтранса России» от 24.05.2024 №21-ОД» с применением программных комплексов с действительными сертификатами соответствия ФСБ России и ФСТЭК России с построением защищенных каналов связи с использованием криптографических методов защиты, сертифицированных ФСБ России). Требования к интеграционной архитектуре могут быть скорректированы и уточнены на этапе разработки Технического проекта по согласованию с Заказчиком

Общий порядок взаимодействия целевого сервиса по подтверждению ЭВПД при оформлении проездного документа для проезда на воздушном и железнодорожном транспорте должен иметь вид: - выбор пассажиром в ИС Перевозчика параметров поездки, ввод данных пассажира и пометка о праве на льготу; - инициализация сеанса связи ИС Перевозчика с сервисом ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификационные данные пассажира; в) особенности пассажира, влияющие на условия перевозки (при наличии); г) параметры поездки; - валидация и трансформация данных с приведением запроса к единому формату; - сквозная проверка согласованности данных между полученным запросом и сведениями об ЭВПД, полученными от ИС Минобороны России через СМЭВ, а именно совпадение: а) идентификационных данных пассажира; б) параметров поездки; в) особенностей пассажира; г) условий перелета/проезда. - формирование расширенного ответа

Состав данных, получаемых из ИС Минобороны России и ИС Перевозчика по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования целевого состояния сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам». Все взаимодействия Систем с ИС Перевозчиков должны осуществляться с учетом организации защищенных каналов связи. Требования к каналам связи должны соответствовать приказу ФГБУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД «Об утверждении Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкций по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных»

4.1.3 Требования к режимам функционирования Функционирование Систем должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Системы должны предусматривать наличие следующих режимов работы: - штатный; - регламентный (профилактический); - аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме Системы обеспечивают возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Систем, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Систем с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Систем и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Систем

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

4.1.4 Показатели назначения Ключевым показателем назначения Систем является выполнение действующих, а также функциональных требований, перечисленных в подразделе 4.2. Архитектура Систем должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание – Изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Системы должны обеспечивать возможность одновременного доступа пользователей (Таблица 7), при условии использования разных учетных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Системы должны обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Систем. Показатели назначения представлены в таблицах ниже (Таблица 7, Таблица 8)

4.2.4.1.2 Развитие метода предоставления сведений об оформленных проездных документах и обновлении их статусов на железнодорожном и воздушном транспорте Развитие текущего метода предоставления перевозчиками сведений по оформленным билетам с применением ЭВПД должна быть реализована путем: ? унификации способа информационного обмена с ИС Перевозчиков; ? расширения атрибутивного состава запроса на детализацию стоимости проездного документа сопутствующих услуг перевозки с обеспечением отражения суммы как с учетом НДС, так и без НДС. При реализации целевого сервиса требуется учесть специфические сценарии переходов статусов и изменение данных проездных документов, в том числе прерывание поездки после отправления поезда с последующим ее возобновлением или без возобновления, а также иных специфических сценариев. Сценарии переходов статусов и изменение данных проездных документов, получаемых ИС Перевозчика, могут быть дополнены или скорректированы на этапе технического проектирования целевого сервиса. Общий порядок взаимодействия целевого сервиса по предоставлению сведений об оформленных проездных документах и обновлении их статусов должен иметь вид: - инициализация связи ИС Перевозчика и сервиса ЭВПД; - передача структурированного запроса в формате JSON, содержащего: а) метаданные запроса (уникальный идентификатор запроса, временная метка); б) идентификатор подтверждения права на проезд; в) идентификатор перевозчика, осуществившего оформление проездного документа; г) пункт продажи; д) сведения о проездном документе (номер, статус); е) даты изменения статуса проездного документа (оформления, возврата, поездки); ж) номер рейса/поезда; и) стоимость поездки, включая дополнительные услуги и НДС (при наличии); - валидация и трансформация данных на уровне сервиса ЭВПД с приведением запроса к единому формату АИС УЛСП; - форматный и логический контроль полученных данных; - формирование расширенного ответа

Состав получаемых и передаваемых данных по согласованию с Заказчиком может быть скорректирован на этапе технического проектирования и отражен в пояснительной записке к техническому проекту и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

Таблица 7 – Показатели производительности Показатель Штатный режим Пиковый режим 1) Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 200 2) Количество одновременных запросов в API 30 200

Таблица 8 – Целевое время отклика Показатель Средняя величина не более, с Максимальная величина не более, с 1) Время отклика на запрос в API 0,2 1 2) Время отклика на запрос в Административной панели: 2.1) при выполнении операций поиска информации 3 10 2.2) при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП и ПСП не учитывает задержку формирования ответа на запрос на стороне системы-источника. Показатели назначения АИС УЛСП и ПСП могут быть уточнены на этапе технического проектирования

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

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

4.1.7 Требования к транспортабельности Требования к транспортабельности Систем не предъявляются

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

4.2.4.2 Требования к интеграции с ИС Минобороны России Оформление ЭВПД осуществляется на стороне ИС Минобороны России. Взаимодействие АИС УЛСП с ИС Минобороны России по оформленным ЭВПД должно быть реализовано посредством СМЭВ. Форматы обмена и структура сообщений должны обеспечивать совместимость с механизмами СМЭВ. Требования к интеграции включают: - использование унифицированных XSD-схем для валидации структуры передаваемых данных; - реализация механизма гарантированной доставки с повторными попытками при сбоях; - ведение журнала межсистемного взаимодействия с фиксацией всех транзакций; - многоуровневая валидация получаемых данных на соответствие XSD-схемам и логический контроль данных; - автоматическое преобразование форматов между СМЭВ и внутренним форматом АИС УЛСП; - разработка механизма уведомления ИС Минобороны России об успешном приеме/отклонении пакетов данных. Проектирование сервиса должно обеспечить разработку единой статусной модели ЭВПД между ИС Минобороны России и АИС УЛСП, гарантирующей синхронизацию и консистентность данных на всех этапах жизненного цикла ЭВПД. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.4.2.1 Требования к реализации получения сведений по оформленным ЭВПД Для реализации получения сведений по оформленным ЭВПД Минобороны России необходимо обеспечить подключение сервиса ЭВПД к соответствующим видам сведений. Набор передаваемых данных по ЭВПД должен включать в себя: - уникальный идентификатор ЭВПД; - статус ЭВПД; - срок действия; - идентификационные данные пассажира; - признак групповой перевозки; - параметры поездки; - особенности пассажира. АИС УЛСП должна обеспечивать для ИС Минобороны России формирование актуализацию справочников пунктов назначения и отправления, указанных в ЭВПД, допустимых для оформления проездных документов. Функциональность должна учитывать специфику городов с несколькими вокзалами/аэропортами. Набор и формат передаваемых данных могут быть скорректированы по согласованию с Заказчиком на этапе технического проектирования и отражены в пояснительной записке к техническому проекту и/или уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.1.9 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.10 Направления развития Систем Система должна предусматривать возможность: - расширения состава внешних и смежных информационных систем-источников информации; - расширения состава внешних и смежных информационных систем-потребителей информации; - расширения состава и наполнения БД АИС УЛСП, НСИ, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание системы; - внедрения дополнительных функциональных подсистем и/или сервисов; - расширения функциональных возможностей существующих подсистем и/или сервисов. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем

4.1.11 Требования к информационной безопасности, включая защиту информации от несанкционированного доступа В ходе выполнения работ по развитию АИС УЛСП и ПСП, осуществляемых в соответствии с настоящим Техническим заданием, должны выполняться требования действующего законодательства по информационной безопасности, распространяемые на Системы. Подрядчик должен быть ознакомлен с Политикой защиты информации Заказчика и гарантировать соблюдение её требований при выполнении работ в части касающейся. Работы по развитию Систем не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированных (развитых) Систем. Подсистемы обеспечения информационной безопасности АИС УЛСП и ПСП разработаны и модернизированы в рамках: ? контракт от 11.10.2022 № 11422211 на выполнение работ по разработке автоматизированной информационной системы управления льготными и субсидированными пассажирскими перевозками; ? контракта от 17.10.2022 № 0373100040322000013 на оказание услуг «Создание системы Портал субсидированных перевозок цифровой платформы транспортного комплекса»; ? контракта от 03.07.2023 № ОК/23_03 «Развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу»; ? контракта от 15.05.2025 № ОК/25_06 на оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации

ПСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00026.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в ПСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

4.2.4.2.2 Требования к реализации предоставления актуальных сведений о статусе ЭВПД Минобороны России Сервис ЭВПД должен обеспечить единую статусную модель между ИС Минобороны России и АИС УЛСП. Статусная модель должна включать следующие состояния ЭВПД: - «получен»; - «обилечен»; - «использован»; - «принят»; - «на проверку»; - «аннулирован»; - «отклонен»; - «ошибка»; Реализация сервиса ЭВПД должна обеспечивать процедуру актуализации информации о состояние ЭВПД для ИС Минобороны России для следующих сценариев: - получение ЭВПД; - продажа билета по ЭВПД; - возврат билета, оформленного по ЭВПД; - наступление времени отчетного периода. Порядок обновления статуса для сценария получения ЭВПД: - АИС УЛСП получает сведения об ЭВПД; - АИС УЛСП посредством СМЭВ направляет статус о принятии ЭВПД. - ИС Минобороны России обновляет статус и завершает оформление ЭВПД. Порядок обновления статуса для сценария продажи билета по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об использовании ЭВПД; - ИС Минобороны России подтверждает принятие статуса и блокирует возможность редактирования ЭВПД; Порядок обновления статуса для сценария возврата билета, оформленного по ЭВПД: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании покупки нового билета по ЭВПД в связи с возвратом ранее оформленного билета. - ИС Минобороны России обновляет статус ЭВПД и открывает доступ к редактированию ЭВПД. Порядок обновления статуса для сценария наступления отчетного периода: - АИС УЛСП посредством СМЭВ направляет в ИС Минобороны России статус об ожидании проверки ЭВПД; - ИС Минобороны России запускает процедуру проверки ЭВПД; - ИС Минобороны России отправляет в АИС УЛСП статус принятия/непринятия ЭВПД

Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

АИС УЛСП аттестована на соответствие требованиям по безопасности информации, что подтверждается Аттестатом от 05.12.2025 № 3515.00027.2025, которым удостоверяется соответствие: ? второму классу защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; ? второго уровня защищенности персональных данных при их обработке в АИС УЛСП в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; ? значимым объектам КИИ Российской Федерации второй категории значимости в соответствии с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»

Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела и данного ТЗ в целом, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках отдельных работ, не предусмотренных данным ТЗ, в том числе подготовка и проведение аттестации Систем, включающих: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы;

4.2.4.3 Требования к реализации межсистемной синхронизации НСИ между участниками информационного взаимодействия Для обеспечения целостности данных и их корректной обработки участниками информационного взаимодействия до начала процесса обмена данными между ИС Минобороны России и АИС УЛСП, а также между АИС УЛСП, ПСП и ИС Перевозчиков требуется провести синхронизацию НСИ. АИС УЛСП должна являться основным источником получения НСИ для ИС Минобороны России и передавать классификаторы и справочники, определяющие следующие параметры: - типы транспорта; - виды ДУЛ; - класс обслуживания / тип вагона; - перечни и идентификаторы пунктов назначения и пунктов отправления на воздушном транспорте и железнодорожном транспорте; - расписание поездов и авиарейсов; - перечень городов с несколькими вокзалами/аэропортами, их идентификаторов и связи с остановочными пунктами; - особенности пассажира. АИС УЛСП должна принимать от ИС Минобороны России, обрабатывать и сохранять информацию по следующим НСИ: - статусы ЭВПД; - статусы отчетных реестров ЭВПД; - связи перевозчиков и пунктов продажи с территориальными УВОСО для формирования отчетности. Перечень и состав получаемой и передаваемой НСИ может быть скорректирован на этапе технического проектирования. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5 Требования к реализации сервиса формирования безбумажной отчетности по воинским перевозкам на железнодорожном или воздушном транспорте на основе прототипа В рамках настоящего ТЗ необходимо реализовать сервис формирования безбумажной отчетности, в том числе по воинским перевозкам на железнодорожном или воздушном транспорте (далее – Сервис отчетности по ЭВПД). Сервис отчетности по ЭВПД должен обеспечивать возможность автоматизированного формирования, передачи, сверки и согласования безбумажной отчетности по воинским перевозкам с использованием ЭВПД. Сервис отчетности по ЭВПД должен предусматривать наличие пользовательского интерфейса личного кабинета Перевозчика (далее – Личный кабинет Перевозчика, ЛК Перевозчика) (п. 4.2.5.1). Сервис отчетности по ЭВПД должен предоставлять следующую функциональность: - формирование безбумажной отчетности по перевозкам отдельных категорий граждан, включая воинских пассажиров; - автоматизированная сверка данных по перевозкам для каждого из участников Эксперимента ЭВПД из числа организаций воздушного и железнодорожного транспорта с размещением результатов сверки в ЛК Перевозчика; - проверка отчетности, в том числе контроль корректности данных перевозок, подлежащих включению в отчетность, экспорт разрешенных данных, формирование детализированного побилетного реестра (отчета), подтверждение реестра (отчета) с помощью специализированных программных механизмов с использованием ЛК Перевозчика, направление реестра (отчета) для акцепта в ИС Минобороны России; - информационное взаимодействие между сервисом отчетности по ЭВПД ИС Минобороны России по передаче электронного детализированного побилетного реестра (отчета) посредством СМЭВ; - приемка из ИС Минобороны России подтвержденного (акцептованного) реестра (отчета) для размещения в ЛК Перевозчика; - формирование в ЛК Перевозчика отчетных форм по акцептованным детализированным побилетным реестрам

– описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; - детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

4.1.12 Требования к разработке Системы 4.1.12.1 Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.12.2. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.12.3 Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

При передаче отчетных сведений и реестров должны обеспечиваться контроль целостности данных, ведение журналов обмена и автоматическое уведомление участников процесса о приеме или отклонении данных. Настоящие требования могут быть уточнены в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.5.1 Требования к реализации пользовательского интерфейса ЛК Перевозчика ЛК Перевозчика предназначен для формирования, согласования и акцептования отчетов по перевозкам, совершенным в том числе с применением ЭВПД. ЛК Перевозчика должен, обеспечивать выполнение следующих задач: - ведение допустимых условий перевозок, согласно заключенным контрактам между перевозчиком и Минобороны России; - контроль корректности данных о перевозках; - корректировка данных о перевозках при выявленных расхождениях; - формирование отчетов по перевозкам с учетом отчетных периодов, определенных условиями контракта между Минобороны России и Перевозчиком; - сохранение истории отправленных отчетов в Минобороны России; - фильтрация отчетов по статусам поездки и отчетному периоду; - ограничение доступа к функциональности ЛК Перевозчика на основе ролевой модели, определяющей права и ограничения функций сервиса; Перечень ограничений для пользовательских ролей должен включать: - ограничения по перевозчику, сотрудником которой является пользователь; - ограничения по региональному филиалу или пункту продажи проездного документа (для ЖД перевозчиков и, при необходимости, для авиаперевозчиков); - ограничения по доступной функциональности. На этапе технического проектирования должны быть определены следующие параметры ролевой модели ЛК Перевозчика: - набор ролей; - права доступа и разрешения, связанные с каждой ролью; - правила назначения ролей пользователям или группам пользователей

4.1.12.4 Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.12.5. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.12.6 Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

4.1.13 Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки

Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода. Руководство должно содержать: ? описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; ? описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; ? описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); ? описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; ? описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; ? утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; ? описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; ? описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности; ? описание процедуры передачи исходного кода от Подрядчика Заказчику.

Функциональные возможности ЛК Перевозчика должны включать: - ведение данных по Перевозчику, заключенным контрактам и данным контрагентов Перевозчиков; - ведение допустимых условий перевозок, согласно заключенному контракту (соглашению) между перевозчиком и Минобороны России: а) ведомство; б) перевозчик; в) виды транспорта (железнодорожный, воздушный); г) категории поезда (для железнодорожного); д) типы вагона (для железнодорожного); е) классы обслуживания; ж) услуги; - анализ сверки данных перевозок, включая: а) обработку пакета данных, предоставленного для сверки; б) отображение результатов сверки, включая: 1) название пакета данных; 2) дату сверки и ее статус; 3) количество билетов, по которым выявлены расхождения, и детали расхождений; - формирование отчетов, включая: а) детализацию отчетов по ведомствам и отчетным периодам; б) указание уникальных номеров ЭВПД, проездных документов и транзакции; в) детали поездки, пунктов отправления, пунктов назначения и стоимости поездки, включая разбивку по услугам и НДС с учетом ставок налогообложения (без НДС, НДС 0%, НДС 10%, НДС 22%); г) фиксацию статуса отчета, его идентификатора, сведений о пользователе, согласовавшем отчет, даты отправки и даты акцептования ведомством. - учет отклоненных Минобороны России проездных документов включая: а) номер ЭВПД; б) причина отказа в акцепте; - корректировку проездных документов, по которым выявлены расхождения, включая: а) идентификационные номера проездных документов и их статус; б) информацию о датах формирования проездного документа и отправления пассажиров; в) причины и содержание корректировки

Перечень отображаемых данных и формат их отображения по согласованию с Заказчиком может быть актуализирован на этапе технического проектирования целевого сервиса и/или уточнен в соответствии с организационно-техническими документами, разрабатываемыми и утверждаемыми в целях исполнения постановления Правительства Российской Федерации от 27.03.2026 № 326 (дсп) «О проведении на территории Российской Федерации эксперимента по переводу воинских перевозочных документов в цифровой формат путем цифрового подтверждения прав воинских пассажиров на оформление проездных документов для проезда на воздушном транспорте и железнодорожном транспорте общего пользования в поездах дальнего следования по воинским перевозочным документам»

4.2.6 Требования к сервису бронирования и оформления проездных документов, в т.ч. оформляемых с подтверждением условий перевозки через сервис, указанный в п. 4.2.4 настоящего Технического задания (далее – Билетный сервис) 4.2.6.1 Функции, подлежащие реализации в Билетном сервисе Билетный сервис должен быть реализован в составе Систем и реализовывать следующий функционал: - интерфейс, реализующий клиентскую часть процесса бронирования и оформления билетов для пассажиров, включая воинских пассажиров и пассажиров, следующих по талонам СФР, включая оформление проездных документов за полную стоимость с возможностью отключения; - интерфейс, который должен выполнять функции Личного кабинета пассажира; - интеграции с ИС бронирования Перевозчиков, сервисами Систем и другими ИС для оформления и бронирования билетов; - получения, хранения и обработки данных, полученных от ИС бронирования Перевозчиков по заданным критериям и ограничениям поискового запроса пассажира; - обработки данных бронирования и оформления электронного проездного документа; - администрирования Билетного сервиса, включая возможность отключения оформления билетов с взиманием платы с пассажиров. Требования подлежат уточнению на этапе технического проектирования. Билетный сервис должен предусматривать применение НСИ, применяемой ИС бронирования Перевозчиков и Системах

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: – проведение статического анализа исходного кода программы; – проведение динамического анализа исходного кода программы; – проведение композитного анализа исходного кода и образов программы; – проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: – предварительных испытаний; – опытной эксплуатации; – приемочных испытаний

По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Систем должен быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком

4.1.14 Требования по сохранности информации при авариях Сохранность информации АИС УЛСП и ПСП должна обеспечиваться Заказчиком. Сохранность информации Систем должна обеспечиваться: - при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; - при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий БД, программных файлов Системы, а также загружаемых файлов; - при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; - при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.2.6.2 Требования к веб-интерфейсу Билетного сервиса Веб-интерфейс Билетного сервиса должен обеспечивать возможность поиска и фильтрации доступных предложений перевозок по заданным параметрам, такими как: - пункт отправления; - пункт назначения; - перевозчик; - дата отправления; - количество пассажиров; - тип пассажира; - класс обслуживания (для воздушного транспорта); - тип вагона (для железнодорожного транспорта); - тип маршрута (в одну сторону, туда и обратно, составной маршрут (только для воздушного транспорта)). Результаты поиска должны предоставляться пользователю в виде перечня доступных предложений перевозок с указанием стоимости и условий применения тарифов. Состав отображаемых сведений при поиске и фильтрации может быть уточнен на этапе технического проектирования, с учетом ограничений и возможностей ИС бронирования Перевозчиков. Составные маршруты должны отображаться для перевозок воздушным транспортом при условии передачи соответствующих данных от ИС бронирования Перевозчиков, в т.ч. при отсутствии прямых рейсов. Должна быть реализована возможность фильтрации по поисковой выдаче, обеспечивающая возможность ограничения перечня отображаемых вариантов перевозки по заданным пассажиром параметрам. Фильтры должны: - обеспечивать интерактивное применение фильтров к результатам поиска; - обеспечивать возможность одновременного применения нескольких фильтров (фасетная фильтрация); - обеспечивать независимую работу фильтров (переключения от множественных фильтров к единичным); - обеспечивать корректную обработку фильтров для маршрутов: а) в одну сторону; б) туда и обратно. - обеспечивать автоматическое формирование доступных значений фильтров на основании результатов поиска; - обеспечивать корректную обработку фильтров при изменении результатов поиска

В интерфейсе должны быть реализованы команды: - «Применить» – выполнение фильтрации результатов поиска; - «Сбросить» – отмена всех установленных фильтров. Должен быть реализован следующий перечень фильтров: - «Количество пересадок». Фильтр предназначен для ограничения результатов поиска по количеству пересадок на маршруте перевозки; - «Перевозчик». Фильтр предназначен для ограничения результатов поиска по Перевозчикам; - «Длительность пересадки». Фильтр предназначен для ограничения результатов поиска по длительности пересадки между сегментами маршрута; - Фильтр «Время вылета/отправления». Фильтр предназначен для ограничения результатов поиска по времени вылета/отправления сегмента маршрута; - «Время прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по времени прилета/прибытия сегмента маршрута; - «Аэропорт/вокзал вылета/отправления». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу вылета/отправления; - «Аэропорт/вокзал прилета/прибытия». Фильтр предназначен для ограничения результатов поиска по аэропорту/вокзалу прилета/прибытия; - «Аэропорт пересадки». Фильтр предназначен для ограничения результатов поиска по месту пересадки. Перечень фильтров может быть уточнен на этапе технического проектирования. Веб-интерфейс Билетного сервиса должен обеспечивать возможность бронирования перевозки по выбранным предложениям на основании действующих нормативных правовых актов, правил перевозок и локальных правовых актов перевозчиков

4.1.15 Требования к патентной чистоте и патентоспособности 4.1.15.1 Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке в соответствии с условиями Контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.15.2 Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.15.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Систем в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.15.4 Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.15.5 Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.1.15.6 В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Систем, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/ сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия – Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО

В рамках указанной функциональности оформления бронирования должно быть обеспечено: - формирование маршрута перевозки на основании выбранных предложений; - расчет итоговой стоимости перевозки; - ввод и обработка данных пассажиров; - получение сведений, необходимых для подтверждения права пассажира на перевозку без взимания платы с пассажира; - бронирование перевозки в ИС бронирования Перевозчика. Веб-интерфейс Билетного сервиса должен обеспечивать возможность оформления основного набора дополнительных услуг при оформлении перевозки воздушным и железнодорожным транспортом. Перечень подлежащих оформлению дополнительных услуг подлежит уточнению на этапе технического проектирования. Должна быть обеспечена возможность: - получения перечня доступных дополнительных услуг; - выбора дополнительных услуг пользователем; - добавления дополнительных услуг в бронирование; - отмена выбора неоплаченных дополнительных услуг. Веб-интерфейс Билетного сервиса должен обеспечивать возможность выбора мест пассажирами при наличии такой функциональности на стороне ИС бронирования Перевозчиков и их технической готовности к передаче и обработке указанных данных. Должно быть обеспечено: - отображение доступных мест; - выбор мест пассажирами; - фиксация выбранных мест в проездном документе.

Веб-интерфейс Билетного сервиса должен обеспечивать возможность вызова функции оплаты проездного документа с использованием внешних платежных инструментов с учетом установленных правил оплаты. Должно быть обеспечено: - формирование запроса на оплату; - получение результата выполнения платежной операции; - обновление статуса бронирования (подтверждение оплаты). Веб-интерфейс Билетного сервиса должен обеспечивать возможность получения проездных документов в электронном виде при завершении оформления. Должно быть обеспечено: - получение проездных документов из ИС бронирования Перевозчиков; - направление сведений и проездных документов в электронном виде. Требования могут быть уточнены на этапе технического проектирования.

4.2.6.3 Требования к Личному кабинету пассажира Личный кабинет пассажира Билетного сервиса должен представлять собой раздел, доступный только авторизованным пользователям. Функционал Личного кабинета должен обеспечивать процессы управления бронированием, включая оформление, поиск оформленного проездного документа (если проездной документ был оформлен через Личный кабинет пассажира Билетного сервиса), получение проездного документа по номеру бронирования и фамилии пассажира, а также возврат проездного документа на воздушный транспорт. Проездной документ, оформленный для проезда на железнодорожном транспорте, может быть возвращен через Билетный сервис в случае, если он был оформлен через Личный кабинет пассажира. Личный кабинет пассажира Билетного сервиса должен обеспечивать возможность разделения бронирования на несколько отдельных бронирований, при наличии технической возможности со стороны ИС перевозчика. Должно быть обеспечено: - выбор пассажиров для выделения в отдельное бронирование; - создание нового бронирования; - перенос выбранных пассажиров. При выполнении разделения бронирования должны соблюдаться следующие правила: - количество взрослых пассажиров в бронировании должно быть не менее количества младенцев без предоставления отдельного места; - в каждом бронировании должно присутствовать не менее одного взрослого пассажира. Авторизация пользователя в Личном кабинете должна происходить с применением типовых механизмов авторизации Систем, в том числе с возможностью применения функционала многофункционального сервиса обмена информацией. Перечень функциональных возможностей Личного кабинета может быть уточнен на этапе технического проектирования

Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого ПО), исходные коды и дистрибутив, инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала Систем, а также документация, указанная в п.5.1 . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.1.15.7 Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.15.8 Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.15.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.15.9 Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.15.10 В случае, если в соответствии с пунктом 4.1.15.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации

4.1.15.11 В случае, если при выполнении Работ положения пунктов 4.1.15.5-4.1.15.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем. 4.1.15.12 Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.1.15.13 По результатам выполнения Работ Подрядчик в составе отчетной документации предоставляет Заказчику материалы и исходные коды доработанной Системы для размещения в Национальном фонде алгоритмов и программ для электронных вычислительных машин (НФАП) в соответствии с требованиями, предусмотренными Постановлением Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»

4.2.6.4 Требования по интеграции с ИС бронирования Перевозчиков и другими ИС для оформления и бронирования билетов Сервис должен интегрироваться с модулями АИС УЛСП, включая ранее разработанные, в части: - получения сведений о наличии у пассажира права на проезд без взимания платы с пассажира, в том числе указанных в п. 4.2.4 настоящего Технического задания; - подтверждения права пассажира на оформление проездного документа на основании данных, полученных от Сервисов, указанных в п. 4.2.4 настоящего Технического задания; - передачи данных о проездных документах, оформленных без взимания платы с пассажира, в том числе в ЛК Перевозчика АИС УЛСП и иные модули Систем (при необходимости) для формирования безбумажной отчетности, согласно п. 4.2.5 настоящего Технического задания. Билетный Сервис должен быть интегрирован и обрабатывать данные ИС бронирования Перевозчиков воздушного транспорта (не менее 2 авиакомпаний) и железнодорожного транспорта (не менее 2 перевозчиков железнодорожного транспорта дальнего следования), обеспечивая клиентский путь полного цикла для пассажира, в том числе следующего без взимания платы с пассажира: поиск билетов по заданным параметрам, фильтрации по параметрам, выбор рейсов, включая выбор мест (для поездов дальнего следования), предоставление пользователю информации об актуальной стоимости проезда с учетом выбранного рейса, класса обслуживания / типа вагона, бронирование и оформление проездного документа, формирования электронного билета по результатам оформления и направления его пассажиру

Информационное взаимодействие должно осуществляться посредством программных интерфейсов (REST API) с обеспечением защищенного канала связи. Все операции, выполняемые сервисом в рамках процессов поиска предложений перевозок, оформления бронирования, оформления дополнительных услуг, оплаты перевозки, обмена и возврата перевозок, должны осуществляться в соответствии с правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими перевозчиками. Выполнение указанных операций должно осуществляться в рамках функциональных возможностей, предоставляемых ИС перевозчиков посредством программных интерфейсов (API). Сервис должен обеспечивать корректную обработку ситуаций, связанных с ограничениями или изменениями API перевозчиков, включая: - недоступность отдельных операций; - изменение формата данных; - отказ в выполнении операции; - ограничение функциональности со стороны перевозчика. В указанных случаях сервис должен обеспечивать: - регистрацию события в журнале; - информирование пользователя о невозможности выполнения операции; - сохранение работоспособности в части обработки корректных запросов. Операции, выполняемые Билетным сервисом в рамках процессов поиска предложений перевозок, действующих тарифов, бронирования мест, оформления проездных документов и дополнительных услуг, взимания платы (если таковое предусмотрено), возврата проездных документов, должны осуществляться в соответствии с действующими нормативными и правовыми актами, правилами применения тарифов, технологическими регламентами и условиями взаимодействия, установленными соответствующими Перевозчиками, при наличии технической и организационной готовности на стороне Перевозчиков, участников взаимодействия и их информационных систем. Организационные взаимодействие с Перевозчиками должно обеспечиваться Заказчиком

5 Состав и содержание работ по развитию АИС УЛСП и ПСП - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Систем, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Систем. В рамках исполнения этапа 1 Подрядчик должен выполнить техническое проектирование по развитию Систем, в соответствии с требованиями, предусмотренными п. 4.1 настоящего ТЗ. В рамках исполнения этапов 2-4 Подрядчик должен выполнить работы по развитию Систем и предварительные испытания, в соответствии с требованиями, предусмотренными п. 4.2.1-4.2.7 настоящего ТЗ. В рамках исполнения этапа 5 Подрядчик должен выполнить работы по проведению опытной эксплуатации и приемочных испытаний Систем, в соответствии с ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» согласно п. 6 настоящего ТЗ - - Значение характеристики не может изменяться участником закупки

5.1. Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Подрядчик по своему усмотрению вправе досрочно приступать к выполнению работ по этапам, при этом принимая на себя все возможные риски, связанные с таким решением. Отчетная, техническая документация, а также результаты работ (ПО) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. № этапа Наименование этапа Результат Срок исполнения этапа

1 Техническое проектирование Систем Согласован с Заказчиком и представлен Технический проект на Систем в следующем составе: - Пояснительная записка - Схема структурная комплекса технических средств; - Схема функциональной структуры; - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. Начало: с даты заключения Контракта; Окончание: не позднее 01.07.2026

2 Выполнение работ по развитию Систем согласно пп. 4.2.2 и 4.2.3 ТЗ и проведение предварительных испытаний Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию. Начало: с 02.07.2026; Окончание: не позднее 28.08.2026

3 Выполнение работ по развитию Систем согласно пп. 4.2.4, 4.2.5 и 4.2.7 ТЗ и проведение предварительных испытаний Систем Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов, - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 25.09.2026

4 Выполнение работ по развитию подсистем АИС УЛСП согласно п. 4.2.6 ТЗ и проведение предварительных испытаний подсистем АИС УЛСП Исходные коды и дистрибутивы на физическом носителе; Акт пуско-наладочных работ. Комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство системного администратора; - Программа предварительных испытаний Систем; - Протокол предварительных испытаний Систем; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию (проект). Начало: с 02.07.2026; Окончание: не позднее 26.10.2026

5 Проведение опытной эксплуатации и приемочных испытаний Систем Программа и методика опытной эксплуатации Систем; Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; Программа инструктажа пользователей; Протокол инструктажа пользователей; Акт о завершении опытной эксплуатации Систем; Программа и методика приемочных испытаний; Отчет о проведении нагрузочного тестирования; Комплект рабочей документации на Системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы); Акт передачи исключительных прав; Акт о готовности ввода Систем в промышленную эксплуатацию; Акт приемки Систем в промышленную эксплуатацию. Начало: с 26.10.2026; Окончание: не позднее 10.11.2026

6 Порядок контроля и приемки - 6.1 Общие требования к выполнению работ по обеспечению проведения испытаний Для доработанных Систем в соответствии с ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» должны быть установлены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Для проведения испытаний назначается комиссия, в состав которой должны входить представители Подрядчика и Заказчика. Комиссия формируется Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний, порядок ее работы, место и сроки проведения испытаний. Перед началом предварительных испытаний Подрядчик выполняет развертывание доработанное ПО Систем на технических средствах Заказчика (ГЦОД). Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов - - Значение характеристики не может изменяться участником закупки

Во время опытной эксплуатации ведется журнал опытной эксплуатации, в который заносятся сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям. До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС. Допускается прохождение предварительных испытаний, опытной эксплуатации и приемочных испытаний с использованием эмуляторов ИС, в случае если за 2 рабочих дня до проведения предварительных испытаний доступ к внешним сервисам, указанным в п. 4.2 ТЗ, не будут представлены Заказчиком. По результатам проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний подрядчик устраняет замечания и дорабатывает ПО Систем, а также выполняет повторное развертывание ПО Систем на технических средствах Заказчика в сроки, указанные в Календарном плане. Передача исходных кодов, разработанных в ходе выполнения работ программ для ЭВМ и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ

Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное ПО, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного ПО, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного ПО. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП

Перед проведением Подрядчиком демонстрации процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ в соответствии с инструкциями, приведенными в рабочей документации на АИС УЛСП и ПСП Подрядчик должен согласовать с Заказчиком требования по развертыванию и проведению вышеуказанных работ. Документация на АИС УЛСП и ПСП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими ИС, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика

6.1.1 Требования к проведению предварительных испытаний Предварительные испытания должны предусматривать проверки соответствия АИС УЛСП и ПСП требованиям данного ТЗ, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП и ПСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП и ПСП должно проверяться: - соответствие АИС УЛСП и ПСП требованиям, установленным в настоящем ТЗ; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП и ПСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП и ПСП. По итогам предварительных испытаний АИС УЛСП и ПСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП и ПСП. Протокол предварительных испытаний АИС УЛСП и ПСП должен содержать заключение о готовности (неготовности) АИС УЛСП и ПСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.1.2 Требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного ПО в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируется весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП и ПСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Акт опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний. Опытная эксплуатация АИС УЛСП и ПСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП и ПСП в рамках этапа № 5 не может длиться менее 10 календарных дней

Целями опытной эксплуатации АИС УЛСП и ПСП являются: - определение полноты реализации требований ТЗ; - определение фактических функциональных характеристик АИС УЛСП и ПСП; - определение готовности персонала к работе в условиях функционирования АИС УЛСП и ПСП; - определение фактической эффективности АИС УЛСП и ПСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП и ПСП должны определяться эксплуатационные характеристики АИС УЛСП и ПСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП и ПСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП и ПСП. Данные опытной эксплуатации АИС УЛСП и ПСП должны заноситься в журнал опытной эксплуатации АИС УЛСП и ПСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП и ПСП. По результатам опытной эксплуатации принимают решение о готовности предъявления АИС УЛСП и ПСП на приемочные испытания, или о неготовности АИС УЛСП и ПСП к приемочным испытаниям АИС УЛСП и ПСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП и ПСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП и ПСП

6.1.3 Требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного ПО. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего ТЗ и по согласованию с Заказчиком. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и ПО, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований ТЗ в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Акт о готовности ввода Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию

Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП и ПСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП и ПСП. На приемочных испытаниях АИС УЛСП и ПСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП и ПСП. В процессе приемочных испытаний АИС УЛСП и ПСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП и ПСП требованиям данного ТЗ. Результаты приемочных испытаний АИС УЛСП и ПСП должны заноситься в протокол приемочных испытаний АИС УЛСП и ПСП. По окончании приемочных испытаний АИС УЛСП и ПСП должен составляться Акт о готовности ввода АИС УЛСП и ПСП в промышленную эксплуатацию. Ввод Системы в промышленную эксплуатацию осуществляется после выполнения работ, предусмотренных п. 4.1.12 ТЗ с подписанием Акта приемки АИС УЛСП и ПСП в промышленную эксплуатацию

6.2 Порядок приемки работ по развитию Систем В целях обеспечения приемки работ по развитию Систем Заказчиком должна быть создана Комиссия по приемке Систем (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика. Приемка Систем осуществляется на основании результатов приемочных испытаний. Приемочные испытания должны проходиться только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приемочные испытания должны проводиться в соответствии с программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приемочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: - дистрибутивный комплект Систем на носителе данных; - программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Системы в порядке, предусмотренном Государственным контрактом. После проведения приемки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

6.3 Сведения о гарантийном обслуживании Систем Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта)

6.4 Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 настоящего ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

7 Требования к документированию - 7.1. Состав документации на систему В рамках выполнения работ по этапу 1 выпускается: - технический проект на Системы в следующем составе: - Пояснительная записка; - Схема структурная комплекса технических средств; - Схема функциональной структуры - Описание автоматизируемых функций; - Описание информационного обеспечения Систем; - Описание организации информационной базы; - Описание программного обеспечения; - Руководство по безопасной разработке ПО; - Ведомость технического проекта; - Ведомость машинных носителей информации. В рамках выполнения работ по этапу 2-4 выпускается: - исходные коды и дистрибутивы на физическом носителе; - акт пуско-наладочных работ. - комплект рабочей документации в составе: - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Общее описание Систем; - Инструкция по сборке и развертыванию дистрибутива ПО; - Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; - Аналитическая записка; - Руководство пользователя «Администратор федерального сегмента»; - Руководство пользователя «Оператор федерального сегмента»; - Руководство пользователя «Оператор СИЦ»; - Руководство пользователя «Оператор региона»; - Руководство пользователя «Сотрудник авиакомпании»; - Руководство пользователя «Сотрудник РОИВ/Росавиации»; - Руководство системного администратора; - Программа предварительных испытаний Системы; - Протокол предварительных испытаний Системы; - Акт инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного ПО; - Акт о приемке Систем в опытную эксплуатацию - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по этапу 5 выпускается: - Программа и методика опытной эксплуатации Систем; - Исходные коды и дистрибутивы на физических носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол пуско-наладочных работ (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке ПО); - Протокол опытной эксплуатации Систем с приложением Журнала опытной эксплуатации Систем; - Программа инструктажа пользователей; - Протокол инструктажа пользователей; - Акт о завершении опытной эксплуатации Систем; - Программа и методика приемочных испытаний; - Отчет о проведении нагрузочного тестирования; - Комплект рабочей документации на системы (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Системы). - Акт передачи исключительных прав; - Акт о готовности ввода Систем в промышленную эксплуатацию; - Акт приемки Систем в промышленную эксплуатацию

7.2. Общие требованию к документации Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 7.1 ТЗ. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105- 2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жесткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе. Разработка ТЗ должна производиться с учетом следующих нормативно-технических документов: - ГОСТ 2.105-2019 «Общие требования к текстовым документам»; - ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»; - ГОСТ 19.105-78 «Общие требования к программным документам»; - ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».?

Преимущества, требования к участникам

Преимущества: Не установлены

Требования к участникам: 1. Требования к участникам закупок в соответствии с ч. 2.1 ст. 31 Закона № 44-ФЗ 1.1? Требования в соответствии c пунктом 4 ПП РФ от 29.12.2021 №2571 Дополнительные требования Наличие у участника закупки опыта исполнения (с учетом правопреемства) в течение трех лет до даты подачи заявки на участие в закупке контракта или договора, заключенного в соответствии с Федеральным законом от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» при условии исполнения таким участником закупки требований об уплате неустоек (штрафов, пеней), предъявленных при исполнении таких контракта, договора. Стоимость исполненных обязательств по таким контракту, договору должна составлять не менее двадцати процентов начальной (максимальной) цены контракта. Информация и документы, подтверждающие соответствие участника закупки дополнительному требованию, установленному в соответствии с частью 2.1 ст. 31 Закона о контрактной системе, являются информация и документы, предусмотренные хотя бы одним из следующих подпунктов: а) номер реестровой записи в предусмотренном Законом о контрактной системе реестре контрактов, заключенных заказчиками (в случае исполнения участником закупки контракта, информация и документы в отношении которого включены в установленном порядке в такой реестр и размещены на официальном сайте единой информационной системы в информационно-телекоммуникационной сети "Интернет"); б) выписка из предусмотренного Законом о контрактной системе реестра контрактов, содержащего сведения, составляющие государственную тайну (в случае исполнения участником закупки контракта, информация о котором включена в установленном порядке в такой реестр); в) исполненный контракт, заключенный в соответствии с Законом о контрактной системе, или договор, заключенный в соответствии с Федеральным законом "О закупках товаров, работ, услуг отдельными видами юридических лиц", а также акт приемки поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену поставленных товаров, выполненных работ, оказанных услуг. 2. Требование к поставщику (подрядчику, исполнителю), не являющемуся субъектом малого предпринимательства или социально ориентированной некоммерческой организацией, о привлечении к исполнению контракта субподрядчиков, соисполнителей из числа субъектов малого предпринимательства, социально ориентированных некоммерческих организаций в соответствии с ч. 5 ст. 30 Закона № 44 ФЗ Дополнительные требования Объем привлечения 50% от цены контракта 3. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 4. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ Показать все (5)

Критерии оценки заявок участников

Обеспечение заявки

Требуется обеспечение заявки: Да

Размер обеспечения заявки: 1 494 000,00 РОССИЙСКИЙ РУБЛЬ

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств или независимой гарантии, оформленной по типовой форме, утвержденной Постановлением Правительства Российской Федерации от 8 ноября 2013 № 1005. Выбор способа обеспечения заявки на участие в закупке осуществляется участником закупки самостоятельно. В соответствии со статьей 44 Федерального закона № 44-ФЗ обеспечение заявки на участие в закупке предоставляется одним из следующих способов: а) путем блокирования денежных средств, внесенных участником закупки на банковский счет, открытый таким участником в банке, включенном в перечень, утвержденный Правительством Российской Федерации (далее - специальный счет). Требования к таким банкам, к договору специального счета, к порядку использования, имеющегося у участника закупки банковского счета в качестве специального счета, устанавливаются Правительством Российской Федерации. б) путем предоставления независимой гарантии. Независимая гарантия, используемая для целей Федерального закона от 05.04.2013 № 44-ФЗ, информация о ней и документы, предусмотренные ч. 9 ст. 45 Федерального закона от 05.04.2013 № 44-ФЗ, должны быть включены в реестр независимых гарантий, размещенный в единой информационной системе. Обеспечение заявки на участие в закупке должно соответствовать ст. 44 Федерального закона от 05.04.2013 N 44-ФЗ. Участники закупки, являющиеся юридическими лицами, зарегистрированными на территории государства - члена Евразийского экономического союза, за исключением Российской Федерации, или физическими лицами, являющимися гражданами государства - члена Евразийского экономического союза, за исключением Российской Федерации, вправе предоставить обеспечение заявок в виде денежных средств с учетом особенностей, установленных Постановлением Правительства Российской Федерации от 10.04.2023 № 579 на счет Заказчика по реквизитам указанным в п. 7.3. Проекта контракта (Приложение № 5 к извещению)

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03214643000000017300, л/c 20736X21630, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/c 40102810545370000003

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО Г. МОСКВЕ (ФГБУ "СИЦ МИНТРАНСА РОССИИ") ИНН: 7704116205 КПП: 770801001 КБК: 00011610000000000140 ОКТМО: 45378000 40102810545370000003 03100643000000017300 004525988

Условия контракта

Номер типовых условий контракта: 1400700000521003

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, г Москва, работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет.

Право заключения контрактов с несколькими участниками закупки в случаях, указанных в части 10 статьи 34 Федерального закона 44-ФЗ: Не установлено

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Обеспечение исполнения контракта

Требуется обеспечение исполнения контракта: Да

Размер обеспечения исполнения контракта: 14 940 000,00 ? (10 %)

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Контракт заключается после предоставления участником закупки, с которым заключается контракт, обеспечения исполнения контракта в соответствии с требованиями Федерального закона № 44-ФЗ. Исполнение контракта может обеспечиваться предоставлением независимой гарантии, соответствующей требованиям статьи 45 Федерального закона № 44-ФЗ, или внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику. Способ обеспечения исполнения контракта, срок действия независимой гарантии определяются в соответствии с требованиями Федерального закона № 44-ФЗ участником закупки, с которым заключается контракт, самостоятельно. Срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии со статьей 95 Федерального закона № 44-ФЗ. В соответствии с Разделом 7 Приложения - Контракт.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03214643000000017300, л/c 20736X21630, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/c 40102810545370000003

Требования к гарантии качества товара, работы, услуги

Требуется гарантия качества товара, работы, услуги: Да

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Гарантийный срок: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 5-му этапу исполнения Контракта). Гарантийные обязательства: Под гарантией понимается надлежащее функционирование Систем в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самих Систем, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Систем в эксплуатацию. Недостатки и ошибки в реализации Систем, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Систем, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в разделе 7 ТЗ), связанные с устранением замечаний к работе Систем или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки).

Информация о требованиях к гарантийному обслуживанию товара:

Требования к гарантии производителя товара:

Обеспечение гарантийных обязательств

Требуется обеспечение гарантийных обязательств: Да

Размер обеспечения гарантийных обязательств: 14 940 000,00 Российский рубль

Порядок предоставления обеспечения гарантийных обязательств, требования к обеспечению: Гарантийные обязательства могут обеспечиваться предоставлением независимой гарантии, соответствующей требованиям статьи 45 Федерального закона № 44-ФЗ, или внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику. Способ обеспечения гарантийных обязательств, срок действия независимой гарантии определяются в соответствии с требованиями Федерального закона № 44-ФЗ участником закупки, с которым заключается контракт, самостоятельно. Срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии со статьей 95 Федерального закона № 44-ФЗ. В соответствии с Разделом 7 Приложения - Контракт.

Платежные реквизиты для обеспечения гарантийных обязательств: p/c 03214643000000017300, л/c 20736X21630, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/с 40102810545370000003

Информация о банковском и (или) казначейском сопровождении контракта

Банковское или казначейское сопровождение контракта не требуется

Документы

Общая информация

Документы

Журнал событий