Об утверждении технических требований к системе обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок

В соответствии с постановлением Правительства Московской области от 10.09.2014 N 726/36 "О целесообразности заключения инвестиционного договора между Правительством Московской области, Государственным унитарным предприятием Московской области "МОСТРАНСАВТО" и организацией, отобранной по результатам открытого конкурса на право заключения инвестиционного договора о реализации инвестиционного проекта по созданию и обеспечению функционирования системы обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок":

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

2. Признать утратившим силу распоряжение Министерства транспорта Московской области от 21.07.2014 N 20РВ-263 "Об утверждении технических требований к системе обеспечения безналичной оплаты проезда Московской области "Единый транспортный билет Московской области".

3. Начальнику Организационного управления Найденову С.И. организовать размещение настоящего распоряжения на официальном сайте Министерства транспорта Московской области.

4. Контроль за выполнением настоящего распоряжения возложить на заместителя министра транспорта Московской области Трусенкову М.Е.

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

Данные технические требования подготовлены во исполнение п. 6 постановления Правительства Московской области от 10.09.2014 N 726/36 "О целесообразности заключения инвестиционного договора между Правительством Московской области, Государственным унитарным предприятием Московской области "МОСТРАНСАВТО" и организацией, отобранной по результатам открытого конкурса на право заключения инвестиционного договора о реализации инвестиционного проекта по созданию и обеспечению функционирования системы обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок" для проведения открытого конкурса на выбор организации.

1.1. Описание проблем, на решение которых направлено создание Системы.

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

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

На сегодняшний день различными вариантами оборудования АСКП оснащено более 5 тысяч транспортных средств, осуществляющих перевозку пассажиров на территории Московской области на регулярных маршрутах по тарифам, установленным Правительством Московской области.

Среди основных проблем обеспечения оплаты проезда на общественном транспорте Московской области для пассажиров можно особенно выделить:

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

отсутствие широкой сети пунктов продажи билетов;

неудобство наличной оплаты проезда непосредственно у кондуктора в салоне транспортного средства;

невозможность использования современных электронных средств платежа для оплаты проезда;

отсутствие гибкой системы скидок на оплату проезда и удобной системы предоплаты.

Среди основных проблем оплаты проезда на общественном транспорте Московской области для перевозчиков можно особенно выделить:

недостаточная защищенность бумажных билетов от подделки;

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

отсутствие технологий автоматизированного учета продажи билетов за наличные средства;

отсутствие технологий оперативного сбора данных об оплаченных поездках и проданных билетах.

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

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

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

1.2. Цели создания Системы.

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

Введение единой транспортной карты позволит:

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

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

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

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

Целью создания Системы для перевозчиков является обеспечение эффективного контроля оплаты проезда и снижение расходов на его организацию за счет:

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

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

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

повышения защищенности билетов от подделки;

снижения доли наличных средств в оплате проезда и расходов на их инкассацию.

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

2.1. Состав Системы.

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

подсистемы обеспечения безналичных расчетов и электронного взаимодействия участников Системы (далее — подсистема расчетов);

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

подсистемы обеспечения деятельности ГУП МО "МОСТРАНСАВТО" по приему электронных средств платежа для оплаты проезда на общественном транспорте (далее — подсистема обеспечения оплаты).

Программная архитектура Системы определяется Инвестором.

2.1.1. Подсистема расчетов.

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

2.1.1.1. Функциональный модуль распространения и пополнения ЕТК.

Модуль предназначен для учета распространения ЕТК, пополнения ЕТК через устройства самообслуживания агентов либо обслуживаемые агентами терминалы пополнения, а также для восстановления неиспользованного количества поездок при повреждении ЕТК.

2.1.1.2. Функциональный модуль тарификации поездок.

Модуль предназначен для ведения нормативно-справочной информации по всем видам применяемых тарифов на перевозку пассажиров и багажа в привязке к маршрутам регулярных перевозок, а также обеспечивает загрузку применяемых тарифов в Подсистемы обеспечения оплаты ГУП МО "МОСТРАНСАВТО" и других перевозчиков.

2.1.1.3. Функциональный модуль авторизации денежных средств и взаиморасчетов с платежными системами.

Модуль предназначен для подготовки и передачи данных об осуществленных запросах на списание денежных средств со счетов банковских карт при оплате поездки или пополнении ЕТК.

2.1.1.4. Функциональный модуль ведения реестра ЕТК.

Модуль предназначен для хранения данных о выпущенных и реализованных ЕТК, а также предоставления механизмов по управлению состояниями ЕТК.

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

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

2.1.1.6. Функциональный модуль управления Стоп-листами ЕТК.

Модуль предназначен для минимизации рисков неоплаты проезда. Подсистема осуществляет актуализацию (добавление/удаление идентификаторов карт) Стоп-листов.

2.1.1.7. Функциональный модуль Web-портала ЕТК.

Модуль предназначен для предоставления пассажирам web-интерфейса управления состоянием ЕТК, обеспечения возможности пополнения и настройки автопополнения ЕТК, а также получения информации об использовании ЕТК. Данный модуль предоставляет пользователям других подсистем, а также пользователям внешних систем, подключенных к Системе, web-интерфейс для получения статистических и других данных о работе Системы.

2.1.1.8. Функциональный модуль ведения и синхронизации НСИ.

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

2.1.1.9. Функциональный модуль мониторинга функционирования, протоколирования событий и предоставления отчетности.

Модуль предназначен для:

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

отображения данных о работе как отдельных ТО, так и группы ТО, размещенных на отдельном ТС подсистемы оплаты ГУП МО "МОСТРАНСАВТО" и других перевозчиков;

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

2.1.1.10. Функциональный модуль мобильного приложения ЕТК.

Мобильное приложение может быть загружено пользователем в смартфон или планшет и предоставляет ему возможности пополнять ЕТК, покупать билеты в электронном виде, получать информацию об истории своих поездок и другие статистические данные.

2.1.1.11. Функциональный модуль ПО контролера.

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

2.1.2. Подсистема учета поездок.

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

2.1.3. Подсистема обеспечения оплаты.

Подсистема обеспечения оплаты представляет собой программно-аппаратный комплекс, решающий задачи оплаты проезда и взаимодействия с Системой для ГУП МО "МОСТРАНСАВТО".

Комплекс включает в себя:

2.1.3.1. Функциональный модуль обеспечения взаимодействия с терминальным оборудованием.

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

2.1.3.2. Функциональный модуль параметризации и управления ТО.

Модуль параметризации и управления ТО устанавливается в ГУП МО "МОСТРАНСАВТО" и предназначен для ведения справочников параметров и ПО ТО, обеспечения загрузки обновления ПО и параметров в ТО в автоматическом режиме или по запросу от ТО.

2.1.3.3. Терминальное оборудование.

Терминальное оборудование перевозчика состоит из одного или более следующих программно-аппаратных комплексов, которые устанавливаются на транспортных средствах ГУП МО "МОСТРАНСАВТО" или которыми оснащаются водители и/или кондукторы ГУП МО "МОСТРАНСАВТО":

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

стационарный терминал водителя;

мобильный терминал оплаты;

мобильный терминал контроля оплаты;

турникет;

датчики мониторинга пассажиропотока.

Функциональные требования к программной части терминального оборудования приведены в разделах 5.2-5.7 настоящих Требований.

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

2.2. Общие требования к Системе.

Система должна обеспечивать:

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

2.2.2. Прием следующих типов карт:

ЕТК;

социальная карта москвича;

социальная карта жителя Московской области;

банковские карты (именные и неименные)

носители с эмуляцией MiFare Classic, MiFare Plus.

2.2.3. Загрузку, хранение, протоколирование изменений и обработку НСИ об остановках, перевозчиках, маршрутах и тарифах и терминальном оборудовании перевозчиков для всей маршрутной сети.

2.2.4. Учет выпущенных и реализованных ЕТК.

2.2.5. Формирование образов электронных билетов.

2.2.6. Взаимодействие с процессинговым центром Банка-эквайера с целью проведения платежей по банковским картам с бесконтактной функцией оплаты.

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

2.2.8. Мониторинг состояния терминального оборудования и программного обеспечения перевозчиков.

2.2.9. Предоставление пассажирам сервисов в виде Web-портала, размещаемого в сети Интернет, и мобильного приложения, дающих пассажиру возможность:

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

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

получения информации о платежах за проезд, оплаченных ЕТК.

В случае если непосредственно в Системе обрабатываются данные платежных карт, то соответствующие модули Системы должны соответствовать стандартам безопасности международных платежных систем PCI-DSS (Payment Card Industry Data Security Standard) и PA DSS (Payment Application Data Security Standard).

Детальный перечень требований к Системе приведен в разделах 4-7 настоящих Требований.

2.3. Требования к взаимодействию Системы с внешними информационными системами.

2.3.1. Перечень внешних информационных систем, с которыми необходимо реализовать интеграцию:

Регистры СКМ, СКМО, ВЕСБ М, ВЕСБ МО льготных категорий граждан (передача информации о выпущенных картах, заблокированных картах, а также о наличии и видах льгот по картам).

Система навигации и контроля выполнения пассажирских перевозок (получение информации по навигации).

Реестр перевозчиков из информационной системы обеспечения деятельности Министерства транспорта Московской области (РПАиТ).

Реестр электронных паспортов маршрутов (ИС ЭПМ РНИС МО).

Региональный портал государственных услуг в части Тематической подсистемы "Транспортный портал" и подсистемы "Личный кабинет".

Внешние сети пополнения ЕТК и платежные шлюзы.

2.3.2. Требования к протоколам взаимодействия в Системе.

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

Должна обеспечиваться передача информации по поездкам, Стоп-листам, параметрам оборудования, географическим координатам мест посадки и высадки пассажиров (или остановкам входа/выхода), в которых производилась оплата проезда и/или регистрация учета поездки или контроль поездки.

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

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

Передача нормативно-справочной информации, на основе которой производится тарификация и/или учет поездок, такой как тарифы, Стоп-листы, паспорта маршрутов и прочее, должна передаваться с усиленной ЭП, включая подтверждение доставки (квитирование) с ЭП и метками даты и времени доставки.

3.1. Общие требования к ЕТК.

3.1.1. Базовый носитель ЕТК — дуальная смарт-карта, соответствующая стандарту ISO/IEC 7816, имеющая бесконтактный интерфейс стандарта ISO/IEC 14443.

3.1.2. В качестве носителя ЕТК может также использоваться' мобильный телефон с поддержкой NFC, банковская карта, УЭК или любой другой носитель, реализующий технологию бесконтактного взаимодействия по стандарту ISO 14443-4.

3.1.3. Каждая карта должна хранить уникальный неизменяемый идентификатор.

3.1.4. На ЕТК должны размещаться идентификатор транспортного приложения и уникальный код для регистрации карты на интернет-сайте Оператора Системы.

3.1.5. На ЕТК может размещаться платежное приложение одной из международных или российских платежных систем.

3.1.6. В случае наличия утвержденных Министерством транспорта Московской области правил размещения транспортных приложений "Тройка" и транспортного приложения ОАО "ЦППК" и ОАО "МТППК" необходимо обеспечить их размещение на ЕТК.

3.1.7. В случае если для реализации беспроводного протокола взаимодействия ЕТК используется лицензированная технология Mifare, необходимо использовать спецификации Mifare, обеспечивающие усиленную защиту: Эмуляция Mifare 1К или Mifare Plus X не ниже Security Level 1.

3.1.8. В случае если для реализации беспроводного протокола взаимодействия ЕТК используется лицензированная технология MasterCard Mchip/4 PayPass или ее аналог, необходимо использовать спецификацию Mchip/4 Advance или ее аналог, обеспечивающие усиленную защиту от несанкционированного доступа с длиной ключей не менее 1024 бит.

3.2. Требования к транспортному приложению ЕТК.

3.2.1. Транспортное приложение ЕТК должно обеспечивать хранение и модификацию по контактному и бесконтактному интерфейсам следующих данных:

Код типа льгот владельца ЕТК.

Остаток суммы на ЕТК.

Дату начала использования ЕТК в текущем месяце.

Накопленную в течение месяца с момента даты начала использования сумму.

Билет(ы) следующего формата:

номер билета;

стоимость билета;

валюта билета;

идентификатор транспортного средства, в котором использовался билет;

дата и время начала поездки;

зона, в которой оплачивается проезд, и/или идентификатор остановки;

зона окончания поездки и/или идентификатор остановки;

тип билета.

3.2.2. Время выполнения одной операции при использовании бесконтактной карты по любому из сценариев, описанных в подразделе 13.1 настоящих требований, не должно превышать 700 мс.

3.2.3. Должна быть обеспечена однозначная идентификация каждого билета ЕТК в операциях.

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

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

3.2.6. Способы управления ключами доступа MiFare должны обеспечивать диверсификации ключей для каждой карты ЕТК и возможность планового и внепланового (срочного, по требованию) обновлений значений ключей доступа, а также информации, служащей основой формирования ключей доступа.

4.1. Функциональные требования к модулю распространения и пополнения ЕТК.

Модуль должен обеспечивать:

4.1.1. Реализовывать сценарии, приведенные в подразделе 13.2 настоящих Требований.

4.1.2. Обработку информации для обеспечения пополнения и продажи ЕТК.

4.1.3. Использование для пополнения киосков самообслуживания и банкоматов.

4.1.4. Поддержку работы с контактным и бесконтактным ридерами для записи данных на ЕТК.

4.1.5. Прием в качестве средств оплаты магнитных, контактных, бесконтактных банковских карт и учет наличных средств.

4.1.6. Прием в качестве средств оплаты и/или пополнения ЕТК электронных средств платежа не менее 5 (пяти) платежных систем, а также оплату со счета мобильного телефона не менее 3 (трех) операторов мобильной связи.

4.1.7. Взаимную аутентификацию при установке связи с подсистемой пополнения ЕТК.

4.1.8. Защищенный канал связи с подсистемой пополнения ЕТК.

4.1.9. Безопасное хранение и использование в точках распространения и пополнения ключей безопасности, используемых для пополнения ЕТК.

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

4.1.11. Реализацию алгоритмов безопасного удаленного изменения состояния ЕТК.

4.1.12. Интерфейс по выбору типа приобретаемого билета или суммы пополнения карты.

4.1.13. Предоставление программного интерфейса другим подсистемам для выполнения операций по удаленному управлению ЕТК.

4.1.14. Предоставление сервис-провайдерам интерфейса и протокола регистрации продажи билетов на разовую поездку мобильного билета или билета, купленного через CMC/USSD.

4.1.15. Предоставление информации о проданных билетах в режиме реального времени.

4.1.16. Проведение сверок с агентами за проданную продукцию.

4.1.17. Расчет комиссии за проданную продукцию.

4.1.18. Восстановление билетов при повреждении карты ЕТК.

4.1.19. Протоколирование обмена данными.

4.1.20. Ведение учета реализованных ЕТК.

4.2. Функциональные требования к модулю тарификации поездок.

4.2.1. Модуль должен поддерживать следующие виды тарифных сеток:

4.2.1.1. Тарифы для ЕТК:

фиксированный тариф на разовую поездку на городском маршруте с дисконтированием по количеству поездок в течение 30 календарных дней;

фиксированный тариф на разовую поездку на специальном участке маршрута;

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

4.2.1.2. Тарифы для банковских карт:

фиксированный тариф на разовую поездку на городском маршруте;

фиксированный тариф на разовую поездку на специальном участке маршрута;

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

4.2.1.3. Тарифы для разовых поездок за наличный расчет:

фиксированный тариф на разовую поездку на городском маршруте;

фиксированный тариф на разовую поездку на пригородном маршруте в пределах одного населенного пункта;

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

4.2.1.4. Тарифы для социальных карт (СКМ, СКМО, ВЕСБ М, ВЕСБ МО):

фиксированный тариф на разовую поездку на городском маршруте;

фиксированный тариф на разовую поездку на специальном участке маршрута;

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

4.2.2. Модуль должен обеспечивать:

web-интерфейс ввода тарифных расстояний для выбранного маршрута перевозчиком и (или) сотрудником Оператора;

загрузку перечня маршрутов и остановок из электронной маршрутной сети РНИС МО.

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

Модуль должен обеспечивать:

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

4.3.2. Поддержку взаимодействия терминал — хост и хост — хост с банковскими процессингами (в случае если данные платежных карт обрабатываются непосредственно в Системе) либо поддержку взаимодействия терминал — хост банка-эквайера.

4.3.3. Соответствие требованиям для получения оператором Системы сертификата на соответствие требованиям PCI DSS (в случае если данные платежных карт обрабатываются непосредственно в Системе).

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

4.4. Функциональные требования к модулю ведения реестра ЕТК.

Модуль должен обеспечить:

4.4.1. Хранение реестра номеров карт и их параметры.

4.4.2. Предоставление интерфейса для осуществления следующих операций с картами:

активация карты;

изменение статуса карты;

изменение данных о предоставляемых пользователю карты льготах.

4.4.3. Интеграцию с другими системами для импорта (экспорта) изменений состояния записи о карте в реестре.

4.5. Функциональные требования к модулю взаиморасчетов с перевозчиками и агентами.

Модуль взаиморасчетов с перевозчиками и агентами должен обеспечить:

4.5.1. Централизованное ведение контрактов с перевозчиками и агентами, ведение параметров контрактов: номера контракта, периода действия, комиссии за обслуживание.

4.5.2. Настройку периода взаиморасчетов для каждого перевозчика (агента по распространению).

4.5.3. Выгрузку агрегированных данных перевозчику (агенту) за период.

4.5.4. Сравнение осуществленных операций и операций перевозчика, подготовку отчетности для взаиморасчетов.

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

4.6. Функциональные требования к модулю управления Стоп-листами ЕТК.

Модуль управления Стоп-листами ЕТК должен обеспечить:

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

4.6.2. Управление внутренней базой Стоп-листов.

4.6.3. Формирование и передачу консолидированного Стоп-листа в ТО.

4.7. Функциональные требования к модулю web-портала ЕТК.

Подсистема web-портала ЕТК должна предоставлять держателю ЕТК следующие возможности:

4.7.1. Настраивать различные варианты и сценарии уведомлений (по СМС, электронной почте, через мобильное приложение) по совершенным по карте операциям (пополнение, гашение, блокировка и т.д.).

4.7.2. Регистрировать пользователей портала с указанием e-mail или мобильного телефона.

4.7.3. Привязывать ЕТК по номеру к учетной записи пользователя.

4.7.4. Предоставлять пользователю сервис по удаленному пополнению ЕТК.

4.7.5. Привязывать электронные средства платежа для автопополнения ЕТК.

4.7.6. Настраивать правила и лимиты автопополнения ЕТК.

4.7.7. Обеспечивать настройку параметров, запуска и доступ к отчетам, генерируемым в Системе.

4.7.8. Обеспечивать разграничение доступа к информации в Системе в соответствии с ролями доступа.

4.8. Функциональные требования к модулю ведения и синхронизации НСИ.

Модуль ведения и синхронизации НСИ должен обеспечить:

4.8.1. Ведение реестра оборудования оплаты.

4.8.2. Обмен информацией с перевозчиками: реестрами маршрутов, остановок, тарифов, терминалов оплаты.

4.8.3. Ведение локальных копий справочников, импортированных из информационных систем РНИС МО.

4.8.4. Обновление справочников из ИС РНИС МО.

4.9. Функциональный модуль мониторинга функционирования, протоколирования событий и предоставления отчетности.

Модуль должен обеспечить:

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

версия ПО, параметров, ключей безопасности, Стоп-листов и OS;

заряд батареи;

координаты местонахождения устройства (в случае наличия GPS/ГЛОНАСС);

количество ошибок считывания карт;

количество ошибок соединения;

от подсистем расчета и учета поездок:

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

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

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

все действия пользователей с административными привилегиями.

4.9.2. Предоставление сервисов в виде Web-портала, размещаемого в сети Интернет, позволяющих формировать и сохранять отчетные формы в общераспространенных форматах данных (txt, csv, xls, pdf):

Для оператора Системы:

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

о загруженных в терминальное оборудование тарифах;

о статистике перевозок (в соответствии с приказом Росстата от 06.09.2012 N 480);

о покупках и использовании билетов;

о статусе работы ТО.

Для пассажиров:

отчет по поездкам, совершенным по его карте ЕТК или банковской карте (с маскированным номером карты).

Для перевозчиков:

отчет о количестве перевезенных пассажиров с указанием кода льготной категории пассажира.

Для муниципальных образований:

отчет о фактическом выполнении рейсов перевозчиком;

отчет о поездках в разрезе маршрутов и перевозчиков;

отчет о перевезенных гражданах льготных категорий.

Для Министерства транспорта Московской области:

отчет по поездкам в разрезе перевозчиков;

отчет о фактическом выполнении рейсов перевозчиками;

отчет о количестве перевезенных пассажиров с указанием кодов льготной категории пассажиров;

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

отчет по поездкам, совершенным по картам ЕТК;

отчет по поездкам, совершенным по банковским картам.

4.10. Функциональные требования к мобильному приложению Системы.

Мобильное приложение пополнения Системы должно реализовывать следующие функции:

4.10.1. Реализовывать сценарии, приведенные в подразделе 13.3 настоящих требований.

4.10.2. Покупку билета на разовую поездку с фиксированной и зональной тарификацией в электронном виде с оплатой безналичным способом.

4.10.3. Гашение билета в электронном виде в автоматическом или ручном режиме с указанием следующих реквизитов билета:

наименование, серия и номер билета;

наименование организации, выдавшей билет;

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

стоимость билета.

4.10.4. Возможность приобретения и погашения не менее двух разовых билетов одновременно.

4.10.5. Отображение билета в электронном виде в виде 2D штрихкода для гашения и/или контроля оплаты проезда и в текстовом виде на экране мобильного телефона.

4.10.6. Авторизацию пользователя ЕТК и регистрацию ЕТК.

4.10.7. Обеспечение доступа пользователя ко всем функциям портала пассажира ЕТК.

4.10.8. Привязку электронных средств платежа к лицевому счету ЕТК для пополнения и автопополнения.

4.10.9. Пополнение карты ЕТК через NFC-интерфейс смартфона.

4.10.10. Информирование о времени прибытия автобуса заданного пользователем маршрута к заданной пользователем остановке с использованием информации и средств ИС РНИС МО или других внешних систем.

4.10.11. Прокладывание маршрута между двумя заданными пользователем точками с использованием маршрутной сети общественного транспорта Московской области как по маршрутам с регулируемыми тарифами, так и по маршрутам с нерегулируемыми тарифами или по всем видам маршрутов по выбору пользователя.

4.10.12. Детектирование сигналов датчиков мониторинга пассажиропотока, установленных на транспортном средстве, и пересылку данных от датчиков мониторинга пассажиропотока и идентификатора мобильного телефона в Систему при входе и выходе пассажира из транспортного средства.

4.11. Функциональные требования к ПО терминала контролера.

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

4.11.1. Реализовывать сценарии, приведенные в разделе 13 настоящего документа.

4.11.2. Аутентификацию контролера на терминале по служебной карте и/или паролю.

4.11.3. Выбор маршрута для проведения контроля оплаты в ручном или автоматическом режиме.

4.11.4. Учет количества проверенных пассажиров в разрезе вида оплаты (учета) проезда, маршрута, транспортного средства с указанием статуса проверки (оплачен/не оплачен проезд), маршрута, идентификатора транспортного средства, тарифной зоны/остановки проверки.

4.11.5. Учет выписанных протоколов об административных правонарушениях.

4.11.6. Выгрузку детальной информации о контроле проезда с терминала контролера в подсистемы расчетов.

4.11.7. Выгрузку информации о работе контролера в подсистемы расчетов.

4.11.8. Возможность объединения контролеров в группу контроля с назначением бригадира, имеющего возможность начать/остановить контроль транспортного средства.

4.11.9. Иметь автоматический режим контроля, обеспечивающий сканирование предъявляемых пассажирами 2D штрихкодов в потоковом режиме.

4.11.10. При проверке погашенного билета приложение контролера должно иметь возможность отображения на экране терминала контролера следующих реквизитов билета:

наименование, серию и номер билета;

наименование организации, выдавшей билет;

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

дату погашения билета;

срок действия билета;

результат проверки билета.

4.11.11. Сохранение в Системе информации:

дату начала и окончания контроля;

состав группы контроля;

уникальный код ТС, на котором проводится контроль;

информацию о проверенных билетах.

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

5.1. Функциональный модуль параметризации и управления ТО подсистемы обеспечения оплаты.

Модуль параметризации и управления ТО устанавливается у Оператора Системы и должен обеспечить:

5.1.1. Хранение справочников различных типов ТО.

5.1.2. Добавление в справочники новых типов оборудования.

5.1.3. Централизованное ведение параметров оборудования.

5.1.4. Настройку параметров для любого типа оборудования.

5.1.5. Применение значений параметров: на выбранное ТО, на выбранные группы ТО, на весь тип оборудования и т.д.

5.1.6. Хранение и обновление ПО оборудования (в ручном или автоматизированном режиме).

5.1.7. Поддержку восстановления параметров или ПО заданной даты и/или версии.

5.1.8. Экспорт параметров в файлы для загрузки в ТО.

5.1.9. Поддержку выгрузки параметров и ПО в ТО.

5.1.10. Протоколирование обмена данными при загрузке параметров.

5.1.11. Управление авторизацией пользователей, имеющих доступ к настройке оборудования.

5.2. Функциональные требования к модулю взаимодействия с терминальным оборудованием.

Модуль взаимодействия с терминальным оборудованием устанавливается в ГУП МО "МОСТРАНСАВТО" и предназначен для ежедневного контроля и ведения статистического учета числа пассажиров, перевозимых на транспортных средствах.

Модуль должен обеспечивать взаимодействие с терминальным оборудованием через подсистему расчетов:

5.2.1. Привязку терминального оборудования к автобусам.

5.2.2. Выбор маршрута для конкретного автобуса.

5.2.3. Возможность выполнения автоматизированной сверки с Системой данных о поездках льготных категорий граждан с социальными картами и платных категорий граждан с оплатой по ЕТК за настраиваемый период.

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

5.2.5. Обеспечение формирования и проверки усиленной электронной подписи для обеспечения юридической значимости электронного документооборота между Подсистемой обеспечения оплаты ГУП МО "МОСТРАНСАВТО" и Подсистемой учета поездок Оператора Системы.

5.2.6. Выгрузку первичной информации о поездках с ТО.

5.2.7. Формирование настраиваемых отчетов о поездках.

5.2.8. Поддержку протоколов обмена данными с подсистемами оператора Системы.

5.3. Функциональные требования к ПО стационарного терминала оплаты.

5.3.1. Прием оплаты проезда в соответствии со сценариями оплаты, гашения билетов, описанными в разделе 13 настоящих требований.

ПО Стационарного терминала оплаты (валидатор) должно обеспечивать:

5.3.2. Прием оплаты проезда в соответствии со сценариями оплаты, гашения билетов и автопополнения баланса карт, описанными в приложениях к настоящим требованиям.

5.3.3. Прием оплаты проезда по банковским бесконтактным картам МПС MasterCard и VISA.

5.3.4. Распознавание 2D штрихкодов для учета поездок, оплаченных с мобильных телефонов (в ТС, оснащенных турникетом).

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

5.3.6. Учет поездок по социальным картам СКМ, СКМО, ВЕСБ М, ВЕСБ МО.

5.3.7. Информирование держателя ЕТК о разрешении (запрете) прохода.

5.3.8. При оплате (учете) проезда отправку запроса на стационарный терминал водителя на разрешение прохода пассажира в случае, если не реализовано локальное хранение стоп-листов.

5.3.9. При разрешении прохода и оплате проезда по ЕТК информирование пассажира об остатке средств на ЕТК.

5.3.10. При разрешении прохода и учете проезда по социальным картам (СКМ, СКМО, ВЕСБ М, ВЕСБ МО) информирование пассажира о сроке действия вышеуказанных социальных карт.

5.3.11. При разрешении прохода и оплате проезда банковской картой производить информирование пассажира о проходе по банковской карте и списанной сумме.

5.3.12. При разрешении прохода и оплате (учете) проезда формирование электронного билета и записывать его в память терминала водителя или на билетный носитель.

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

5.3.14. В случае нестабильной связи или временного отсутствия связи формировать пакеты в очереди для пересылки и передавать в момент восстановления связи.

5.3.15. Загружать с терминала водителя или из подсистемы расчетов изменения в Стоп-листах карт через настраиваемый промежуток времени от 30 секунд до 30 минут через шину данных или запрашивать наличие карты в Стоп-листе для каждой поездки.

5.4. Функциональные требования к ПО стационарного терминала водителя.

ПО Стационарного терминала водителя должно обеспечивать:

5.4.1. Включение, выключение и перезагрузку подключенных валидаторов.

5.4.2. Управление подключенными турникетами, в том числе:

передавать ответ о разрешении прохода на турникет;

диагностировать неисправность турникета.

5.4.3. Аутентификацию водителя на терминале по служебной карте и/или паролю.

5.4.4. Загрузку перед началом смены НСИ из подсистемы параметризации и управления терминалами оплаты (поддерживать полную и частичную загрузку):

тарификации проезда;

маршрутов и остановок (тарифных зон);

Стоп-листов карт ЕТК, банковских карт, СКМ, СКМО, ВЭСБ МО и ВЭСБ М.

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

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

5.4.7. В случае нестабильной связи или временного отсутствия связи формирование пакетов в очереди для пересылки на сервер и передачу в момент восстановления связи.

5.4.8. Прием информации по оплате проезда от валидаторов.

5.4.9. Загрузку параметров терминала оплаты из подсистемы параметризации и управления терминалами оплаты.

5.4.10. Передачу на валидатор разрешения/отказа на проход на основании наличия карты в Стоп-листе или загрузку Стоп-листов в валидатор.

5.4.11. Передачу информации в подсистемы расчетов в режиме реального времени (пакетная передача по настраиваемому графику или исходя из объема накопленной информации).

5.4.12. Передачу информации о работоспособности системы оплаты и данных о количестве поездок различных категорий пассажиров в режиме реального времени (пакетная передача по настраиваемому графику или исходя из объема накопленной информации).

5.4.13. Передачу журналов регистрации событий по расписанию.

5.4.14. Передачу срочных оповещений по факту их регистрации о неработоспособности или выключении оборудования.

5.4.15. Загрузку из Системы изменений в Стоп-листах карт (пакетная передача по настраиваемому графику или исходя из объема накопленной информации).

5.4.16. Прием информации от внешнего или встроенного GPS/ГЛОНАСС приемника о текущих координатах и передачу данных в Систему и РНИС МО.

5.4.17. Мониторинг и протоколирование статуса работоспособности самого терминала оплаты и подключенных к нему устройств (валидаторов, турникетов).

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

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

5.5. Функциональные требования к ПО турникета.

ПО Турникета должно обеспечивать:

5.5.1. Получение информации с терминала оплаты на разрешение (запрет) прохода пассажира.

5.5.2. Разрешение (запрет) прохода.

5.5.3. Включение, выключение и перезагрузку турникета по сигналу с терминала оплаты.

5.6. Функциональные требования к ПО мобильного терминала оплаты (терминала кондуктора).

ПО Мобильного терминала оплаты должно обеспечивать:

5.6.1. Прием оплаты проезда по банковским бесконтактным картам МПС MasterCard и VISA.

5.6.2. Аутентификацию кондуктора на терминале по служебной карте и/или паролю.

5.6.3. Перед началом смены загрузку НСИ из подсистемы расчетов (поддерживать полную и частичную загрузку):

по тарификации проезда;

о маршрутах и остановках (тарифных зонах);

о Стоп-листах карт ЕТК, банковских карт, СКМ, СКМО, ВЭСБ МО и ВЭСБ М.

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

5.6.5. Печать билетов на разовую поездку при оплате за наличный расчет или по банковской карте на принтере со штрихкодом для контроля.

5.6.6. В случае нестабильной связи или временного отсутствия связи формирование пакетов в очереди для пересылки на сервер и передачу в момент восстановления связи.

5.6.7. Обмен информацией с подсистемой расчетов в режиме реального времени (пакетная передача по настраиваемому графику или исходя из объема накопленной информации с задержкой не более 10 минут).

5.6.8. Передачу информации о погашенных электронных билетах и данных об оплате по ЕТК и банковским картам и за наличный расчет.

5.6.9. Передачу информации о регистрации поездок по социальным картам.

5.6.10. Передачу информации о работоспособности терминального оборудования и ошибках.

5.6.11. Загрузку изменений в Стоп-листах всех поддерживаемых видов карт.

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

5.6.13. Мониторинг и протоколирование статуса работоспособности самого терминала оплаты.

5.6.14. Передачу журналов регистрации на сервер КФИС и в подсистему расчетов по расписанию.

5.6.15. Загрузку параметров конфигурации терминала оплаты из подсистемы расчетов по расписанию.

5.6.16. Прием и учет оплаты проезда:

по ЕТК в соответствии со сценариями оплаты, гашения билетов и автопополнения баланса карт, описанными в разделе 0 настоящих требований;

по банковским бесконтактным картам МПС MasterCard и VISA (опционально);

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

по социальным картам СКМ, СКМО, ВЕСБ М, ВЕСБ МО.

5.6.17. Визуальную и звуковую индикацию и информирование пассажира и кондуктора:

О факте успешной (неуспешной) оплаты или учета поездки.

В случае если проезд уже оплачен, отображение факта оплаты на экране.

При оплате проезда по ЕТК информирование пассажира об остатке средств на ЕТК.

При учете проезда по социальным картам (СКМ, СКМО, ВЕСБ М, ВЕСБ МО) информирование пассажира о сроке действия вышеуказанных социальных карт.

При оплате проезда банковской картой информирование пассажира о списанной сумме.

5.6.18. При разрешении прохода и оплате (учете) проезда формирование электронного билета и его запись в память терминала оплаты или на билетный носитель (ЕТК).

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

5.6.20. По служебной карте контролера и/или паролю отображение текущего количества учтенных наличных денег с момента последней сдачи выручки.

5.7. Функциональные требования к датчикам мониторинга пассажиропотока.

Датчики мониторинга пассажиропотока должны обеспечивать генерацию идентифицирующих транспортное средство уникальных сигналов по протоколу Bluetooth 4.0 (ИДУ) в объеме, покрывающем всю площадь транспортного средства с настраиваемой частотой генерации.

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

6.1. Функциональный модуль УПЛКГ должен обеспечивать:

6.1.1. Информационный обмен с внешними автоматизированными информационными системами реестров социальных карт:

Загрузка и агрегация реестров социальных карт (в том числе Стоп-листов) из внешних автоматизированных систем.

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

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

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

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

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

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