Региональное
Законодательство
Московская область

Распоряжение Министерства транспорта МО от 12.09.2014 N 20РВ-319 "Об утверждении технических требований к системе обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок"

МИНИСТЕРСТВО ТРАНСПОРТА МОСКОВСКОЙ ОБЛАСТИ

РАСПОРЯЖЕНИЕ
от 12 сентября 2014 г. № 20РВ-319

ОБ УТВЕРЖДЕНИИ ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ К СИСТЕМЕ ОБЕСПЕЧЕНИЯ
БЕЗНАЛИЧНОЙ ОПЛАТЫ ПРОЕЗДА ПАССАЖИРОВ И ПЕРЕВОЗКИ БАГАЖА
НА ОБЩЕСТВЕННОМ ТРАНСПОРТЕ МОСКОВСКОЙ ОБЛАСТИ, УЧЕТА
ПРОДАННЫХ БИЛЕТОВ И СОВЕРШЕННЫХ ПОЕЗДОК

В соответствии с постановлением Правительства Московской области от 10.09.2014 № 726/36 "О целесообразности заключения инвестиционного договора между Правительством Московской области, Государственным унитарным предприятием Московской области "МОСТРАНСАВТО" и организацией, отобранной по результатам открытого конкурса на право заключения инвестиционного договора о реализации инвестиционного проекта по созданию и обеспечению функционирования системы обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок":
1. Утвердить технические требования к системе обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок согласно приложению к настоящему распоряжению.
2. Признать утратившим силу распоряжение Министерства транспорта Московской области от 21.07.2014 № 20РВ-263 "Об утверждении технических требований к системе обеспечения безналичной оплаты проезда Московской области "Единый транспортный билет Московской области".
3. Начальнику Организационного управления Найденову С.И. организовать размещение настоящего распоряжения на официальном сайте Министерства транспорта Московской области.
4. Контроль за выполнением настоящего распоряжения возложить на заместителя министра транспорта Московской области Трусенкову М.Е.

Министр транспорта
Московской области
А.Ю. Зайцев





Приложение
к распоряжению Министерства
транспорта Московской области
от 12 сентября 2014 г. № 20РВ-319

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
К СИСТЕМЕ ОБЕСПЕЧЕНИЯ БЕЗНАЛИЧНОЙ ОПЛАТЫ ПРОЕЗДА ПАССАЖИРОВ
И ПЕРЕВОЗКИ БАГАЖА НА ОБЩЕСТВЕННОМ ТРАНСПОРТЕ МОСКОВСКОЙ
ОБЛАСТИ, УЧЕТА ПРОДАННЫХ БИЛЕТОВ И СОВЕРШЕННЫХ ПОЕЗДОК

Термины и определения

Таблица № 1

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

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

1. Введение

Настоящий документ определяет функциональный состав системы обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок (далее - Система), а также общие технические требования к Системе и ее функциям.
Данные технические требования подготовлены во исполнение п. 6 постановления Правительства Московской области от 10.09.2014 № 726/36 "О целесообразности заключения инвестиционного договора между Правительством Московской области, Государственным унитарным предприятием Московской области "МОСТРАНСАВТО" и организацией, отобранной по результатам открытого конкурса на право заключения инвестиционного договора о реализации инвестиционного проекта по созданию и обеспечению функционирования системы обеспечения безналичной оплаты проезда пассажиров и перевозки багажа на общественном транспорте Московской области, учета проданных билетов и совершенных поездок" для проведения открытого конкурса на выбор организации.
1.1. Описание проблем, на решение которых направлено создание Системы.
Действующая в настоящее время система оплаты проезда пассажиров и провоза багажа на общественном транспорте Московской области ориентирована прежде всего на использование наличных денежных средств.
В деятельности отдельных транспортных организаций, осуществляющих перевозку пассажиров по маршрутам регулярных перевозок по регулируемым тарифам с предоставлением мер социальной поддержки отдельным категориям граждан, используются автоматизированные системы контроля оплаты проезда (далее - АСКП) для учета поездок льготных категорий граждан (с использованием СКМО) и приема месячных проездных билетов (в виде транспортных карт).
На сегодняшний день различными вариантами оборудования АСКП оснащено более 5 тысяч транспортных средств, осуществляющих перевозку пассажиров на территории Московской области на регулярных маршрутах по тарифам, установленным Правительством Московской области.
Среди основных проблем обеспечения оплаты проезда на общественном транспорте Московской области для пассажиров можно особенно выделить:
необходимость приобретения отдельных проездных билетов у разных перевозчиков;
отсутствие широкой сети пунктов продажи билетов;
неудобство наличной оплаты проезда непосредственно у кондуктора в салоне транспортного средства;
невозможность использования современных электронных средств платежа для оплаты проезда;
отсутствие гибкой системы скидок на оплату проезда и удобной системы предоплаты.
Среди основных проблем оплаты проезда на общественном транспорте Московской области для перевозчиков можно особенно выделить:
недостаточная защищенность бумажных билетов от подделки;
необходимость для перевозчиков содержания кондукторов для продажи бумажных билетов непосредственно в салонах транспортных средств;
отсутствие технологий автоматизированного учета продажи билетов за наличные средства;
отсутствие технологий оперативного сбора данных об оплаченных поездках и проданных билетах.
Действующая система оплаты проезда на общественном транспорте не позволяет органам государственной власти объективно оценить финансовые результаты работы перевозчиков на отдельных маршрутах и направлениях, рациональность установленных тарифов и эффективность деятельности пассажирского транспорта в целом. Преобладание оборота наличных денежных средств также способствует нарушениям финансовой дисциплины.
Недостаток информации о выручке не позволяет сформировать сбалансированную систему транспортных услуг, отвечающую текущим потребностям населения, а также разработать рациональные мероприятия по повышению привлекательности пассажирского транспорта общего пользования.
В этой связи применение новых электронных технологий, способных значительно снизить оборот наличных денежных средств в сфере пассажирских перевозок, является своевременным и необходимым шагом на пути к созданию эффективной транспортной системы регионального уровня.
1.2. Цели создания Системы.
Целью создания Системы для пассажиров является обеспечение простоты и удобства оплаты проезда на общественном транспорте за счет введения в обращение единой транспортной карты и реализации возможностей безналичной оплаты проезда.
Введение единой транспортной карты позволит:
обеспечить возможность оплаты проезда в безналичном виде с использованием одного универсального средства оплаты и приобретения билетов у разных перевозчиков в электронном виде;
отказаться от практики приобретения месячных проездных билетов и создать условия для введения программ лояльности и реализации гибкой системы скидок на оплату проезда (чем больше ездишь, тем больше скидка);
реализовать возможности удобного пополнения единых транспортных карт, в том числе удаленно, с использованием электронных средств платежа;
обеспечить эффективный контроль расходов на оплату проезда на общественном транспорте.
Целью создания Системы для перевозчиков является обеспечение эффективного контроля оплаты проезда и снижение расходов на его организацию за счет:
отказа от использования кондукторов для продажи бумажных билетов;
экономии на распространение билетной продукции за счет использования создаваемой сети пунктов распространения и пополнения единых транспортных карт;
внедрения современных автоматизированных технологий контроля пассажиропотока и оплаты проезда;
повышения защищенности билетов от подделки;
снижения доли наличных средств в оплате проезда и расходов на их инкассацию.
Целью создания Системы для Министерства транспорта Московской области является получение полной, оперативной и достоверной информации о пассажирских перевозках (в том числе о перевозках льготных категорий граждан) с целью эффективного регулирования рынка пассажирских перевозок в регионе.

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 № 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. Требования к Единой Транспортной Карте

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. Функциональные требования к подсистеме расчетов

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 № 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. Функциональные требования к подсистеме обеспечения оплаты

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. Функциональные требования к подсистеме учета поездок

Подсистема учета поездок передается Оператору Системы с исходными кодами и документацией для модернизации. В рамках работ по модернизации необходимо обеспечить реализацию следующего функционала.
6.1. Функциональный модуль УПЛКГ должен обеспечивать:
6.1.1. Информационный обмен с внешними автоматизированными информационными системами реестров социальных карт:
Загрузка и агрегация реестров социальных карт (в том числе Стоп-листов) из внешних автоматизированных систем.
При разработке данной функциональности в обязательном порядке должны быть учтены следующие требования:
Подключение к информационным системам служб социальной защиты должно осуществляться по защищенному каналу связи.
Загрузка реестров должна выполняться на периодической основе, период должен настраиваться.
Должен вестись лог загрузки. В случае наличия ошибок при загрузке должна быть предусмотрена процедура информирования персонала, занятого техническим обслуживанием системы.
Должен быть реализован механизм подтверждения полной доставки данных.
Программное обеспечение агрегации реестров должно быть легко расширяемо с целью добавления новых типов социальных карт, информационных систем служб социальной защиты (источников данных).
6.1.2. Загрузка реестров перевозчиков, осуществляющих перевозку льготных категорий граждан, и реестров ТО из Системы.
Загрузка данных должна происходить в защищенном ЭП виде.
Должен вестись лог загрузки. В случае наличия ошибок при загрузке предусмотреть процедуру информирования персонала, занятого техническим обслуживанием системы.
Должен быть реализован механизм подтверждения полной доставки данных из Системы.
6.1.3. Загрузка информации о маршрутах, тарифах, на которых принимаются к оплате социальные карты, из Системы.
Загрузка данных должна происходить в защищенном ЭП виде.
Должен вестись лог загрузки. В случае наличия ошибок при загрузке предусмотреть процедуру информирования персонала, занятого техническим обслуживанием системы.
6.1.4. Должен быть реализован механизм подтверждения полной загрузки информации по поездкам.
6.1.5. Хранить данные о транспортных транзакциях проезда по социальным картам в течение определенного (настраиваемого) периода времени, но не менее 3 (трех) лет.
6.1.6. Формирование отчетности о перевозке льготных категорий граждан в соответствии с распоряжениями Министерства транспорта Московской области.
Предоставление органам власти дополнительных сервисов в виде личных кабинетов, обеспечивающих возможности получения информации о совершенных перевозках льготных категорий граждан в различных разрезах.
Формирование статистических отчетов для органов статистики, Министерства транспорта Московской области и федеральных органов власти в соответствии с установленными формами.
6.1.7. Формирование отчетов для транспортных предприятий в соответствии с установленными формами.
6.2. Функциональный модуль КФИС должен обеспечивать:
6.2.1. Доступ к модулю КФИС должен быть реализован через Web-портал.
6.2.2. Предоставлять данные о количестве перевезенных пассажиров:
детализированная информация о факте осуществления перевозки с указанием Компании перевозчика, типа транспорта, типа оплаты проезда, дате и времени проезда, маршрута, пунктах отправления и назначения;
консолидированная информация по перевозчикам с указанием суммирующей информации по общему количеству поездок, по количеству поездок по банковским картам, по социальным картам, по наличным;
консолидированная информация в разрезе перевозчика и маршрута с указанием суммирующей информации по общему количеству поездок, по количеству поездок по банковским картам, по социальным картам, по наличным.
6.2.3. Предоставлять данные о количестве распространенных и погашенных билетов:
детализированная информация о покупке и использовании билетов;
консолидированная информация по общему количеству купленных билетов, погашенных поездок.
6.2.4. Предоставлять данные по используемой транспортными предприятиями тарификации с возможностью детализации по маршрутам.
6.2.5. Предоставлять информацию по работе транспортных предприятий:
количество используемых терминалов для приема оплаты;
процент принятых оплат с использованием карт;
процент невыгруженных транзакций с терминала;
количество перевезенных пассажиров льготных категорий;
процент перевезенных пассажиров льготных категорий;
сумма совершенных поездок пассажирами льготных категорий.
6.2.6. Данные должны предоставляться как в режиме "офлайн", так и в режиме "онлайн".
6.2.7. По всей предоставляемой информации должна быть предусмотрена возможность фильтрации по дате начала и окончания.
6.2.8. По всей предоставляемой информации должна быть реализована возможность экспорта в формат MS Excel, PDF.

7. Нефункциональные требования к Системе

7.1. Показатели назначения Системы.
7.1.1. Система должна выполнять требуемый функционал при следующих значениях показателей назначения:
Система должна обеспечивать обслуживание не менее 5 млн. ЕТК.
Система должна обеспечивать обслуживание не менее 5 млн. социальных карт.
Система должна обеспечивать прием и обработку информации не менее чем от 15 тыс. транспортных средств.
Система должна обеспечивать прием и обработку информации не менее чем от 5 тыс. точек пополнения и продаж ЕТК.
Все ТО должны хранить до 3 млн. записей в Стоп-листе.
Система должна обеспечивать хранение информации о транзакциях за период не менее чем 5 лет.
Время обработки одной транзакции оплаты проезда по картам на ТО не должно превышать 0,7 сек.
Время обработки одной транзакции пополнения ЕТК не должно превышать 5 сек. на стороне Оператора.
Время построения отчета/графика - не более 2 минут (за период не более 6 месяцев).
Периодичность синхронизации данных между подсистемами расчетов и ТО не должна превышать 10 минут при наличии связи.
Мобильные ТО должны обеспечивать 12 часов непрерывной работы.
7.2. Требования к режимам функционирования Системы.
7.2.1. Каждая подсистема, входящая в состав Системы, должна иметь следующие основные режимы функционирования:
Штатный - основной режим функционирования. В данном режиме подсистема выполняет свои функции в соответствии с техническими и организационными инструкциями.
Сервисный режим - режим, при котором должен производиться пуск, остановка и перезапуск подсистемы, резервное копирование накопленных данных, обновление системного и прикладного программного обеспечения, изменение конфигурационных параметров подсистемы. При переключении в данный режим допустимо непродолжительное снижение общей производительности Системы. Сервисный режим не должен требовать приостановки работы пользователей Системы в целом.
Аварийный режим - режим, который должен позволять использовать доступные ресурсы подсистемы для сохранения информации, правильного закрытия информационных массивов работающих приложений и операционных систем. Аварийный режим должен использоваться для выполнения минимально необходимых операций в условиях аварийного энергоснабжения компонентов подсистемы или выхода из строя части оборудования.
7.2.2. При условии регулярного регламентного обслуживания и мониторинга параметров работы подсистем Система в целом должна обеспечивать длительно-непрерывное, круглосуточное функционирование в штатном режиме и в сервисном режиме.
7.3. Требования к программному обеспечению Системы.
7.3.1. Программное обеспечение подсистем Системы должно обладать открытой, модульной архитектурой и представлять собой совокупность общесистемного и специального программного обеспечения.
7.3.2. Общесистемное программное обеспечение Системы должно представлять совокупность программных средств со стандартными интерфейсами, предназначенных для организации и реализации информационно-вычислительных процессов в каждой подсистеме.
7.3.3. Операционные системы и системы управления базами данных, используемые в Системе, должны быть (по возможности) свободно распространяемыми.
7.3.4. Прикладное программное обеспечение Системы должно представлять собой совокупность прикладных программ, реализующих весь спектр функциональных задач подсистем.
7.3.5. Прикладное обеспечение должно позволять проводить оперативную адаптацию функциональных задач подсистем Системы при возникновении новых требований пользователей в процессе эксплуатации.
7.3.6. Оператор Системы должен передать Правительству Московской области дистрибутив прикладного программного обеспечения на стандартном машинном носителе (CD/DVD).
7.3.7. Оператор Системы должен передать набор спецификаций и протоколов взаимодействия, позволяющих сторонним производителям программного обеспечения реализовывать следующие функции:
прием ЕТК на новых устройствах;
организация пополнения ЕТК.
7.3.8. Оператор Системы должен обеспечить предоставление протокола и сервиса, позволяющего встраивать функции пополнения ЕТК и оплаты с помощью мобильного электронного билета в приложения для смартфонов, разработанные сторонними разработчиками ПО.
7.3.9. Передача указанных документов третьим лицам не должна приводить к понижению информационной безопасности системы.
7.3.10. Исходные коды прикладного программного обеспечения должны быть задокументированы.
7.3.11. Передача исходных кодов прикладного программного обеспечения должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, специальной среды разработки (за исключением покупных изделий) и т.п.
7.3.12. Система должна функционировать в режиме времени, близком к реальному, в едином информационном пространстве.
7.3.13. Пользовательские интерфейсы всех подсистем, входящих в состав Системы, должны функционировать без дополнительных ограничений на автоматизированных рабочих местах пользователей в среде следующих интернет-браузеров: Microsoft Internet Explorer (версия 8 и выше), Google Chrome (версия 30 и выше), Mozilla Firefox (версия 24 и выше), Safari не ниже 5 версии или их аналогов, но с возможностью (при необходимости) установки дополнительных бесплатных компонент. Для автоматизации рабочих мест сотрудников Перевозчика допускается использование АРМ, работающих в среде операционной системы Windows 7 и выше.
7.3.14. Общее и специальное программное обеспечение Системы должно быть установлено с применением системы виртуализации.
7.3.15. Система должна предусматривать функционирование во всех режимах и восстановление с применением системы виртуализации.
7.3.16. Доступ к Web-порталу должен происходить только по протоколу https.
7.3.17. Для всех соединений с внешними системами должны быть реализованы защищенные протоколы обмена данными.
7.3.18. Данные, передаваемые с оборудования перевозчиков, должны быть подписаны ключами безопасности.
7.3.19. Должен быть обеспечен механизм авторизированного доступа к функциям SAM модулей.
7.3.20. Все криптографические операции с использованием ключей, сохраненных в SAM модуле, должны производиться внутри SAM модуля таким образом, чтобы ключевая информация никогда не выгружалась из SAM модуля.
7.3.21. ПО, загружаемое в любые виды оборудования, должно быть подписано усиленной неквалифицированной ЭП оператора Системы или любым другим способом, гарантирующим возможность контроля целостности ПО. При запуске должен обеспечиваться контроль целостности ПО. Запуск ПО без подтверждения целостности должен быть ограничен.
7.3.22. Подсистемы должны включать в себя средства автоматизированного тестирования.
7.3.23. Мобильные приложения для пополнения ЕТК и покупки мобильных билетов должны быть разработаны для ОС iOS версий 6.0 и выше, Android версий 2.3.3 и выше и Windows Phone версий 7.5 и выше.
7.3.24. Поступающие данные должны проходить обработку средствами форматно-логического контроля. В случае нарушения правил форматно-логического контроля подсистема должна уведомлять пользователя об обнаруженных нарушениях и предоставлять ему возможность исправить их.
7.4. Требования к надежности технических средств и программного обеспечения Системы.
7.4.1. Система должна функционировать в режиме 365/24/7. Отказ любой подсистемы не должен приводить к остановке работы всей Системы (при этом допускается временное снижение производительности). Сохранность данных должна обеспечиваться за счет отказоустойчивых дисковых массивов и регулярного резервного копирования критичных данных.
7.4.2. Для обеспечения показателей надежности все используемые аппаратные средства Системы, каналы питания и передачи данных должны иметь горячее резервирование.
7.4.3. Система не должна прекращать штатную работу при пропадании электропитания по одному из вводов.
7.4.4. Система должна быть подключена к информационно-телекоммуникационной сети не менее чем по двум независимым каналам связи с пропускной способностью, обеспечивающей функционирование Системы в соответствии с показателями назначения.
7.4.5. Надежность Системы должна достигаться комплексом организационных и технических мер, обеспечивающих требуемые уровни безотказности, ремонтопригодности, долговечности и сохранности ресурсов.
7.4.6. Система относится к обслуживаемым восстанавливаемым изделиям общего назначения многократного циклического применения согласно ГОСТ 27.003.90.
7.4.7. Сохранность работоспособности и информации в Системе в пределах значений показателей надежности, приведенных ниже, должна обеспечиваться при возникновении следующих аварийных ситуаций:
отказы в электроснабжении;
отказы серверного оборудования;
отказы сетевого, телекоммуникационного оборудования и каналов связи;
отказы оборудования подсистемы резервного копирования информации;
отказы программных средств;
отказы общего программного обеспечения;
отказы специального программного обеспечения;
отказы в результате ошибок обслуживающего персонала и пользователей.
7.4.8. Требования по надежности, которым должны удовлетворять подсистемы расчетов и учета поездок, а также подсистема обеспечения оплаты, приведены ниже (таблица № 2, таблица № 3).

Таблица № 2

ПОКАЗАТЕЛИ НАДЕЖНОСТИ ПОДСИСТЕМ РАСЧЕТОВ И УЧЕТА ПОЕЗДОК

N
Показатель
Значение
1
Режим работы
режим 365 дней/год x 24 часа, останов. на профилактические работы в промежуток с 1.00 до 4.00
2
Показатель доступности
0,998
3
Время восстановления работоспособности Подсистемы после отказа или проведения регламентных работ
не более 4 часов
4
Суммарное время на восстановление работоспособности и регламентное обслуживание Системы
не более 17,5 часа в год

Таблица № 3

ПОКАЗАТЕЛИ НАДЕЖНОСТИ ТО ПОДСИСТЕМЫ ОБЕСПЕЧЕНИЯ ОПЛАТЫ

N
Показатель
Значение
1
Режим работы
режим 365 дней/год x 20 часов, останов. на профилактические работы в промежуток с 1.00 до 4.00
2
Показатель доступности (в среднем на комплект оборудования для одного автобуса)
0,998
3
Время восстановления работоспособности Подсистемы после отказа или проведения регламентных работ
не более 4 часов
4
Суммарное время на восстановление работоспособности и регламентное обслуживание оборудования на один комплект (в том числе методом замены)
не более 14,6 часа в год

7.5. Требования к эргономике и технической эстетике.
7.5.1. Все экранные формы пользовательского интерфейса подсистем Системы должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и назначения.
7.5.2. Интерфейс подсистем должен быть понятен и удобен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве Системы.
7.5.3. Все сообщения, надписи и иные текстовые элементы интерфейса должны быть выполнены на русском языке. Исключения могут составлять только системные сообщения, выдаваемые сторонними программными продуктами.
7.5.4. Содержание каждой экранной формы должно отображаться полностью без дополнительного горизонтального прокручивания при разрешении экрана не менее 1024 x 768 точек.
7.5.5. Навигационные и управляющие элементы интерфейса должны быть выполнены в удобной для пользователя форме с соблюдением следующих условий:
однозначность наименований (наименование элемента должно позволять однозначно определить его назначение);
унификация наименований (однотипные элементы должны иметь одинаковые наименования);
унификация обозначений (однотипные элементы должны иметь одинаковые обозначения - графические значки, вид кнопок и т.п.);
унификация использования (однотипные элементы должны иметь одинаковую реакцию на действия пользователя - наведение указателя, переключение фокуса, нажатие кнопки).
7.5.6. В интерфейсах подсистем должна быть предусмотрена возможность применения клавиш быстрого доступа для выбора наиболее часто используемых функций.
7.5.7. Пользователь должен иметь возможность гибко контролировать ввод данных: просматривать введенные данные на мониторе, производить их корректировку или отказаться от ввода.
7.5.8. При вводе данных по возможности должны использоваться справочники и шаблоны ввода информации.
7.5.9. Интерфейс подсистем Системы не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм.
7.5.10. При выполнении длительных процессов подсистемы Системы должны выдавать индикатор хода выполнения процесса.
7.5.11. Каждая подсистема должна быть снабжена средствами корректной обработки аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных (выдача пользователю соответствующих сообщений, затем - возвращение в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных). Сигнализация об ошибках или ошибочных действиях должна сопровождаться индикацией на экране и/или звуковым сигналом и/или подсказкой о дальнейших действиях.
7.6. Требования к модернизации Системы.
7.6.1. Подсистемы должны разрабатываться с учетом перспектив развития, модернизации и масштабирования Системы. Развитие и модернизация Системы должны быть предусмотрены по следующим направлениям:
добавление новых подсистем и пользовательских сервисов;
расширение функциональных возможностей подсистем в ходе развития Системы;
улучшение технических характеристик Системы, таких как производительность серверов и рабочих станций, коммутационного оборудования и оборудования маршрутизации, пропускной способности каналов связи;
расширение состава взаимодействующих внешних автоматизированных систем;
расширение состава и наполнения справочников и классификаторов Системы.
7.6.2. Подсистемы, входящие в Систему, должны допускать модернизацию, связанную с модернизацией технического обеспечения, операционного окружения, применением новых современных интерфейсов информационного взаимодействия, методов и протоколов передачи данных. Подсистемы также должны предусматривать возможность быстрой модернизации при изменении положений нормативно-правовых актов, определяющих предмет автоматизации.
7.6.3. Подсистемы Системы должны иметь возможность адаптироваться к изменяющимся требованиям в процессе эксплуатации (изменениям в законодательстве, автоматизируемых процессах, методах управления и т.д.) преимущественно путем настройки и конфигурирования.
7.6.4. Система должна модернизироваться за счет добавления, замены или модернизации подсистем, при этом модернизация одной подсистемы не должна требовать модернизации других подсистем, входящих в состав Системы.
7.6.5. Подсистемы должны обеспечивать возможность наращивания производительности путем увеличения производительности комплекса технических средств (КТС). Пригодность подсистем к увеличению производительности должна определяться наличием процедуры модернизации, обеспечиваемой путем настройки общесистемного программного обеспечения, без внесения изменения в программный код подсистем Системы.
7.7. Требования к патентной чистоте Системы.
7.7.1. Программные и технические средства Системы, приобретаемые у сторонних организаций, должны быть обеспечены всеми необходимыми сертификатами и лицензиями. При разработке основных системотехнических решений и специального программного обеспечения не должны использоваться решения третьих фирм, защищенные патентами или иными действующими на территории Российской Федерации документами, удостоверяющими авторские права на них, без соответствующего лицензионного соглашения с авторами данных решений. Выполнение требований по обеспечению лицензионной чистоты программного обеспечения обеспечивается Исполнителем.
7.8. Требования к документированию Системы.
7.8.1. Техническая и эксплуатационная документация должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы:
ГОСТ 34.003-90, ГОСТ 19.004-80-82 - в части терминологии;
ГОСТ 34.201-89, ГОСТ 19.101-77-82 в части наименования и обозначения документов.
7.8.2. Формальное полное соответствие документов требованиям РД 50-34.698-90 и ЕСПД по составу и структуре разделов не требуется, исключая документ "Руководство пользователя". При этом должно быть достигнуто адекватное описание всех видов обеспечения, достаточное для подготовки персонала, установки, настройки, эксплуатации и сопровождения подсистем Системы по всем позициям, определяемым РД 50-34.698-90 и ЕСПД для отдельных документов.
7.8.3. Документы должны представляться в двух экземплярах на бумажном носителе и в одном экземпляре на электронном носителе.
7.8.4. Документация должна содержать полное описание всех интерфейсов подключения внешних информационных систем и спецификации протоколов взаимодействия с ними.
7.8.5. Отчетные материалы должны быть оформлены на листах формата А4 и А3 без рамки, основной надписи и дополнительных граф к ней, предусмотренных ГОСТ 2.301-68. Номера листов (страниц) проставляют начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине).
7.8.6. На титульном листе помещают наименование отчетного материала, учетные реквизиты (если необходимо), подписи Исполнителя, скрепленные печатью (для организаций).
7.8.7. Документация передается на бумажных (два экземпляра) и на машинных носителях (CD/DVD). Текстовые документы, передаваемые на машинных носителях, должны быть представлены в формате MS Office 2010 и выше (шрифт Times New Roman, размер шрифта - 12, межстрочный интервал - 1,5).
7.8.8. Комплект эксплуатационной документации в части программного обеспечения должен содержать исчерпывающее описание прикладного программного обеспечения согласно ЕСПД, обеспечивающее его установку, настройку, эксплуатацию и сопровождение (технические требования (спецификации), а также все спецификации на приложения карты и терминального оборудования, описания алгоритмов и протоколов обмена данными между всеми компонентами Системы.
7.9. Требования к защите информации от несанкционированного доступа.
7.9.1. Несанкционированный доступ к данным Системы должен быть ограничен следующими средствами:
административными и организационными средствами - размещение серверного и коммуникационного оборудования Системы и средств обеспечения ее бесперебойной работы должно осуществляться в физически защищенных помещениях. Доступ в указанные помещения должен быть строго ограничен с помощью соответствующих технических средств контроля. Должны быть разработаны специальные административные регламенты, контролирующие порядок доступа в указанные помещения, а также регулирующие доступ к данным Системы;
административными программными средствами операционной системы, базы данных, прикладными функциями обеспечения информационной безопасности и специальными средствами защиты к отдельным ее компонентам и приложениям;
ограничением доступа к данным Системы программными средствами СУБД, операционных систем и прикладного ПО в соответствии с ролями пользователей;
осуществлением передачи информации по каналам связи и хранением резервных копий данных Системы с применением средств криптографической защиты;
межсетевыми экранами для отделения сетей общего пользования от создаваемых в рамках Системы ведомственных сетей с особыми требованиями к безопасности, которые должны быть определены соответствующими регламентами, обеспечивающими сетевую безопасность;
другими техническими и программными средствами защиты, обеспечивающими достаточный уровень защиты в соответствии с разработанной моделью угроз и применимыми нормативными документами и стандартами по защите информации.
7.9.2. Должен обеспечиваться контроль корректности и целостности данных, служащих основанием взаиморасчетов в Системе.
7.10. Требования к контролю целостности данных, поступающих с ТО.
7.10.1. Протокол обмена данными между ТО и другими подсистемами должен позволять однозначно определить:
ТО, на котором были выполнены операции. Для этого все пакеты, передаваемые с ТО, быть подписаны уникальным для каждого устройства закрытым ключом.
Время выполнения операций. Для этого информация обо всех операциях, передаваемая с ТО, должна включать в себя информацию о времени выполнения каждой операции. Время на ТО должно быть синхронизировано со временем подсистемы расчетов.

8. Порядок контроля и приемки Системы

8.1. Общие требования к приемке работ.
8.1.1. Приемка результатов выполнения работ оформляется Актом выполненных работ. Основанием для составления и подписания Акта выполненных работ является передача Оператором Системы результатов работ в соответствии с условиями инвестиционного договора и настоящих требований и подписание технических актов на подсистемы.
8.1.2. В процессе согласования и утверждения документации должна осуществляться проверка ее полноты и качества.
8.1.3. Испытание документации на полноту и качество должно заключаться в оценке:
комплектности состава документации;
соответствия документации требованиям настоящих требований;
полноты и ясности изложения организационных, технических и экономических аспектов описываемых явлений и процессов.
8.1.4. Процесс согласования и утверждения документации должен заключаться не только в выявлении ошибок изложения, но и в выработке правильных (корректных) формулировок и редакций исследуемого документа.
8.1.5. Приемка стадий работ осуществляется комиссией, в состав которой входят представители Оператора, Министерства государственного управления, информатизации и связи Московской области и Министерства транспорта Московской области. По результатам приемки подписывается Акт приемки работ.
8.2. Виды, состав, объем и методы испытаний Системы и ее составных частей.
8.2.1. Место проведения испытаний предоставляется Оператором Системы.
8.2.2. Цель проведения приемочных испытаний - проверка соответствия Системы требованиям, определенным настоящими требованиями.
8.2.3. Испытания должны быть организованы и проведены в соответствии с ГОСТ 34.603-92.
8.2.4. До начала приемочных испытаний Оператор Системы передает Министерству транспорта Московской области полный набор технической и эксплуатационной документации, а также аутентификационных данных для доступа к Системе, необходимых для ее установки, настройки, эксплуатации и модернизации.
8.2.5. До начала приемочных испытаний Оператор Системы создает и согласовывает с Министерством транспорта Московской области и Министерством государственного управления, информатизации и связи Московской области программу и методику приемочных испытаний.
8.2.6. При проведении испытаний в части информационного взаимодействия Системы с другими ИС проверяется наличие в Системе и соответствие установленным требованиям сервисов приема/передачи данных. Возможность проверки реального информационного взаимодействия производится в случае предоставления операторами ИС данных, определенных соответствующим регламентом информационного взаимодействия.
8.2.7. Приемочные испытания проводятся комиссией, формируемой Министерством транспорта Московской области на основании распорядительного документа, который должен определять состав комиссии проведения испытаний, порядок ее работы, место и сроки проведения испытаний.
8.2.8. В состав комиссии включаются представители Министерства транспорта Московской области, Министерства государственного управления, информатизации и связи Московской области, ГУП МО "МОСТРАНСАВТО" и Оператора Системы.
8.2.9. Объем и методы приемочных испытаний определяются соответствующей Программой и методикой приемочных испытаний, разработанной Оператором Системы и согласованной с Министерством транспорта Московской области и Министерством государственного управления, информатизации и связи Московской области в составе рабочей документации.
8.2.10. Приемочные испытания должны быть проведены на полной копии Системы после контрольной компиляции исходных кодов, установки и настройки в соответствии с технической документацией.
8.2.11. Результаты приемочных испытаний должны быть зафиксированы в Протоколе приемочных испытаний (с указанием выявленных недостатков Системы и их уровня критичности - высокий, средний, низкий). При выявлении недостатков Системы Министерство транспорта Московской области направляет Оператору Предписание об устранении недостатков. Оператор устраняет недостатки и направляет Министерству транспорта Московской области Отчет об устранении недостатков.
8.2.12. По результатам приемочных испытаний составляется акт о приемке Системы в промышленную эксплуатацию.

9. Требования к внедрению Системы

9.1. При подготовке ко вводу Системы в эксплуатацию Оператор Системы обеспечивает выполнение следующих работ:
определяет подразделение и ответственных должностных лиц, ответственных за внедрение и проведение эксплуатации Системы;
проводит обучение персонала перевозчиков по работе с Системой;
обеспечивает выполнение требований, предъявляемых к программно-техническим средствам, на которых должно быть развернуто программное обеспечение Системы;
готовит план установки и запуска Системы на технических средствах.
Внедрение Системы должно производиться поэтапно в соответствии с целевыми показателями проекта и детальным планом внедрения, разработанным Оператором Системы и согласованным Министерством транспорта Московской области и Министерством государственного управления, информатизации и связи Московской области.
9.2. Обязательными этапами внедрения являются:
запуск подсистемы расчетов и подсистемы учета поездок в опытную эксплуатацию;
запуск подсистемы обеспечения оплаты ГУП МО "МОСТРАНСАВТО" в опытную эксплуатацию на всех транспортных средствах ГУП МО "МОСТРАНСАВТО" с использованием оборудования согласно Типовой конфигурации № 1 (таблица № 15);
запуск подсистемы обеспечения оплаты ГУП МО "МОСТРАНСАВТО" в опытную эксплуатацию транспортных средств ГУП МО "МОСТРАНСАВТО" с использованием оборудования согласно Типовой конфигурации № 2 (таблица № 16, таблица № 17, таблица № 18);
запуск Системы в промышленную эксплуатацию в полном объеме.

10. Требования к эксплуатации Системы

10.1. Общие требования к обслуживанию Системы.
10.1.1. В течение всего срока действия Договора Оператор Системы должен обеспечить функционирование Системы в соответствии с данными техническими требованиями и согласованными с Министерством транспорта Московской области и Министерством государственного управления, информатизации и связи Московской области регламентами обслуживания Системы.
10.1.2. В случае нарушения функционирования Системы Оператор должен восстановить работоспособность в срок, определенный показателями надежности каждой подсистемы.
10.1.3. Оператор Системы должен реализовать службу сервис-деск с помощью интернет-сайта.
10.1.4. Оператор Системы должен организовать процессы поддержки подсистем, управления настройками в соответствии с ITIL v2.
10.2. Требования к обслуживанию оборудования подсистемы расчетов.
10.2.1. В течение всего срока действия Договора Оператор Системы должен производить своевременное обслуживание и модернизацию оборудования и программного обеспечения подсистемы расчетов в соответствии с требованиями производителей оборудования и разработчиками программного обеспечения.
10.2.2. Техническую поддержку подсистемы предлагается осуществлять посредством трехуровневой системы следующим образом:
уровень 1 и уровень 2 - специалистами Оператора Системы;
уровень 3 - специалистами поставщика оборудования и (или) программного обеспечения системы.
Специалисты службы поддержки Оператора Системы являются штатными сотрудниками Оператора и решают следующие задачи:
единая и доступная точка контакта для перевозчиков и пользователей ЕТК;
регистрация электронных заявок для передачи во 2 уровень поддержки;
обеспечение мониторинга работоспособности оборудования (на основании поступающей в Систему информации), формирование электронных заявок на диагностику нештатной работы оборудования, обеспечение информационного взаимодействия между тремя уровнями поддержки;
решение обращений пользователей, требующих технических компетенций;
локализация проблем, которые не могут быть разрешены специалистами Оператора Системы, и передача их экспертам поставщика оборудования;
участие в приемочных испытаниях новых версий программного обеспечения и оборудования;
аналитическая работа по формулированию и управлению требованиями и изменениями к программному обеспечению и оборудованию.
Специалисты Поставщика оборудования и (или) Программного обеспечения решают следующие задачи:
гарантийное и послегарантийное обслуживание программного обеспечения и оборудования;
реализация требований и изменений программного обеспечения и оборудования;
негарантийный ремонт оборудования.
10.2.3. При обслуживании оборудования:
осуществляется оценка дефектов элементов оборудования;
решение о замене отдельных компонент оборудования происходит индивидуально для каждого компонента комплекта оборудования;
для отдельных компонентов оборудования предусматривается плановая обязательная замена в соответствии с установленной периодичностью.
10.2.4. Устанавливаются следующие уровни сервиса для 1 и 2 уровня поддержки подсистемы обеспечения оплаты.

Таблица № 4

ТРЕБУЕМЫЕ ПАРАМЕТРЫ КАЧЕСТВА СЕРВИСА
ДЛЯ 1 И 2 УРОВНЯ ПОДДЕРЖКИ


Параметр
Значение
1
Режим работы поддержки
режим 365 дней/год x 20 часов, по телефону
заявки через интернет-сайт (сервис-деск)
режим 365 дней/год x 24 часа
2
Время реакции на заявку на 1 и 2 уровне поддержки
1 час

10.2.5. Устанавливаются следующие уровни сервиса для 3 уровня поддержки подсистемы обеспечения оплаты.

Таблица № 5

ТРЕБУЕМЫЕ ПАРАМЕТРЫ КАЧЕСТВА СЕРВИСА ДЛЯ 3 УРОВНЯ ПОДДЕРЖКИ


Параметр
Значение
1
Режим работы поддержки
режим 5 x 7 дней в неделю x 8 часов, по телефону
заявки через интернет-сайт (сервис-деск)
режим 365 дней/год x 24 часа
2
Время реакции на заявку на 3 уровне поддержки
8 часов

10.3. Требования к обслуживанию оборудования подсистемы обеспечения оплаты.
10.3.1. В течение всего срока действия Договора Оператор Системы должен производить своевременное обслуживание и модернизацию оборудования и программного обеспечения подсистемы обеспечения оплаты в соответствии с требованиями производителей оборудования и разработчиками программного обеспечения.
10.3.2. Оператор обеспечивает оснащение ГУП МО "МОСТРАНСАВТО" оборудованием (стационарными валидаторами и мобильными терминалами) в количестве, достаточном для обеспечения нормативного выпуска транспортных средств, а также ЗИП/обменный фонд в размере, достаточном для оперативной замены в случае выхода из строя для обеспечения заданных показателей доступности.
10.3.3. ГУП МО "МОСТРАНСАВТО" обеспечивает собственными средствами логистику оборудования в автопарки, колонны, отстойно-разворотные площадки и т.д.
10.3.4. ГУП МО "МОСТРАНСАВТО" внутренними нормативными документами устанавливает правила контроля и обращения оборудования с целью обеспечения оснащения выходящих ТС оборудованием и оперативной замены в случае их поломки.
10.3.5. Техническую поддержку оборудования, устанавливаемого на транспортные средства и используемого для целей функционирования подсистемы обеспечения оплаты, предлагается осуществлять посредством трехуровневой системы следующим образом:
уровень 1 - специалистами службы поддержки ГУП МО "МОСТРАНСАВТО";
уровень 2 - специалистами Оператора Системы;
уровень 3 - специалистами Поставщика оборудования.
10.3.6. Специалисты службы поддержки ГУП МО "МОСТРАНСАВТО" являются штатными сотрудниками ГУП МО "МОСТРАНСАВТО" и решают следующие задачи:
единая и доступная точка контакта для пользователей оборудования (водители, кондуктора и т.д.);
обучение пользователей оборудования;
решение вопросов и запросов пользователей, не требующих высокой технической квалификации (в пределах компетенции);
локализация проблем, которые не могут быть разрешены специалистами службы поддержки ГУП МО "МОСТРАНСАВТО", и передача их специалистам Оператора системы/Поставщика оборудования;
простейшая диагностика работоспособности оборудования, оперативная замена (за счет передаваемого резервного оборудования);
формирование электронных заявок на тех. обслуживание специалистами Поставщика;
доставка оборудования, требующего ремонта, в адрес Оператора Системы/Поставщика (по согласованию с ГУП МО "МОСТРАНСАВТО").
10.3.7. Для обеспечения поддержки специалистами службы ГУП МО "МОСТРАНСАВТО" в ходе поставки и установки оборудования Оператор Системы/Поставщик оборудования обязан провести специальные обучающие семинары.
10.3.8. Специалисты службы поддержки Оператора Системы решают следующие задачи:
обеспечение мониторинга работоспособности оборудования (на основании поступающей в Систему информации), формирование электронных заявок на диагностику нештатной работы оборудования, обеспечение информационного взаимодействия между тремя уровнями поддержки;
решение обращений пользователей, требующих технических компетенций, которыми не обладают специалисты службы поддержки ГУП МО "МОСТРАНСАВТО";
локализация проблем, которые не могут быть разрешены специалистами Оператора Системы, и передача их экспертам поставщика оборудования;
участие в приемочных испытаниях новых версий программного обеспечения и оборудования;
аналитическая работа по формулированию и управлению требованиями и изменениями к программному обеспечению и оборудованию;
специалисты Оператора помогают специалистам службы поддержки ГУП МО "МОСТРАНСАВТО", являются технологическими консультантами и посредниками при разрешении плановых и оперативных вопросов со специалистами Поставщика оборудования.
10.3.9. Специалисты Поставщика оборудования решают следующие задачи:
гарантийное и послегарантийное обслуживание программного обеспечения и оборудования;
реализация требований и изменений программного обеспечения и оборудования;
негарантийный ремонт оборудования.
10.3.10. При обслуживании оборудования:
осуществляется оценка дефектов элементов оборудования;
решение о замене отдельных компонент оборудования происходит индивидуально для каждого компонента комплекта оборудования;
для отдельных компонентов оборудования предусматривается плановая обязательная замена в соответствии с установленной периодичностью.
10.3.11. При выявлении случаев выхода из строя оборудования, не связанных с виной Поставщика оборудования или Оператора системы, компенсация соответствующих расходов по восстановлению работоспособности оборудования осуществляется ГУП МО "МОСТРАНСАВТО" самостоятельно.
10.3.12. Устанавливаются следующие уровни сервиса для 2 уровня поддержки подсистемы обеспечения оплаты.

Таблица № 6

ТРЕБУЕМЫЕ ПАРАМЕТРЫ КАЧЕСТВА СЕРВИСА ДЛЯ 2 УРОВНЯ ПОДДЕРЖКИ


Параметр
Значение
1
Режим работы
поддержки
режим 365 дней/год x 20 часов, по телефону
заявки через интернет-сайт (сервис-деск)
режим 365 дней/год x 24 часа
2
Время реакции на заявку на 2 уровне поддержки
1 час

10.3.13. Устанавливаются следующие уровни сервиса для 3 уровня поддержки подсистемы обеспечения оплаты.

Таблица № 7

ТРЕБУЕМЫЕ ПАРАМЕТРЫ КАЧЕСТВА СЕРВИСА ДЛЯ 3 УРОВНЯ ПОДДЕРЖКИ


Параметр
Значение
1
Режим работы поддержки
режим 5 x 7 дней в неделю x 8 часов, по телефону
заявки через интернет-сайт (сервис-деск)
режим 365 дней/год x 24 часа
2
Время реакции на заявку на 3 уровне поддержки
8 часов

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

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

Таблица № 8

ТРЕБОВАНИЯ К ТЕРМИНАЛАМ КОНДУКТОРА


Параметр
Значение
1
Операционная система
Android, Windows, Linux либо другая операционная система реального времени
2
Память, не менее
8 MB ROM/FLASH
3
Интерфейсы внешние
USB или RS-232
4
Коммуникации
Модем (EDGE/3G/GSM) и/или Wi-fi (802.11 b/g)
5
Бесконтактный ридер
Соответствие ISO 14443
6
Сканер штрихкодов
Поддержка 2D штрихкодов, оптический (допускается использование внешнего модуля/устройства или любого другого механизма/технологии проверки подлинности мобильного билета)
7
Вес
Не более 600 г без чехла (встроенный принтер), не более 400 г (без принтера)
8
Звук
Наличие звуковой индикации
9
Питание
Не менее 12 часов работы
10
Диапазон рабочих температур, не меньше
От 0 до +50 °C
11
Поддержка модулей безопасности
Не менее 1 модуля SAM
12
Допустимая влажность при работе
Не менее 90% без конденсации
13
Принтер
Встроенный или внешний (подключаемый по Bluetooth), ширина ленты не менее 40 мм со скоростью печати не менее 60 мм/сек.
14
Общие требования
Поддержка протоколов MiFare Classic (1k, 4k), MiFare Plus
Прием карт MasterCard PayPass, VISA Pay Wave (опционально)
15
Навигация (опционально)
Встроенный или внешний приемник GPS или GPS/ГЛОНАСС
16
Защищенность (опционально)
Не ниже IP54, возможность падения с высоты не менее 1 м (не менее 5 раз) на бетонный пол

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

Таблица № 9

ТРЕБОВАНИЯ К ТЕРМИНАЛАМ КОНТРОЛЕРА


Параметр
Значение
1
Операционная система
Android, Windows, Linux либо другая операционная система реального времени
2
Память, не менее
8 MB ROM/FLASH
3
Расширение памяти
Возможность установки расширения памяти до 16 Gb
4
Интерфейсы внешние
USB
5
Коммуникации
Модем (EDGE/3G/GSM) и/или Wi-fi (802.11 b/g), Bluetooth V2.0 и выше
6
Бесконтактный ридер
Соответствие ISO 14443
7
Сканер штрихкодов
Поддержка 2D штрихкодов, оптический (допускается использование внешнего модуля/устройства или любого другого механизма/технологии проверки подлинности мобильного билета)
8
Вес
Не более 400 г без чехла
9
Экран
Экран размером не менее 1,5" с поддержкой Touch Screen (в случае отсутствия клавиатуры)
10
Звук
Наличие звуковой индикации
11
Питание
не менее 12 часов работы
12
Поддержка модулей безопасности
Не менее 1 модуля SAM
13
Диапазон рабочих температур, не меньше
От 0 до +50 °C
14
Допустимая влажность при работе
Не менее 90% без конденсации
15
Навигация (опционально)
Встроенный или внешний приемник GPS или GPS/ГЛОНАСС
16
Защищенность (опционально)
Не ниже IP54, возможность падения с высоты не менее 1 м (не менее 5 раз) на бетонный пол

11.3. Требования к стационарным терминалам водителя.
Оборудование для стационарных терминалов оплаты должно соответствовать требованиям, указанным в таблице № 10.

Таблица № 10


Параметр
Значение
1
Операционная система
Android, Windows, Linux либо другая операционная система реального времени
2
Память
Не менее 64 МБ RAM, не менее 128 МБ ROM
3
Расширение памяти
Возможность установки расширения памяти до 32 Gb
4
Интерфейсы внешние
USB Host, подключение до 6 внешних валидаторов по CAN, RS485 или Ethernet
5
Коммуникации
Модем (HSPA + /HSPA/UMTS, EDGE/GSM) с возможностью подключения внешней антенны, Wi-fi (802.11 b/g) с возможностью работы в режиме точки доступа
6
Сканер штрихкодов (в конфигурации для совместной работы с турникетом)
Поддержка 2D штрихкодов, встроенный или внешний
7
Принтер (в случае отсутствия принтера в валидаторе)
Встроенный или внешний принтер с автоматической отрезкой билета, ширина ленты не менее 40 мм со скоростью печати не менее 60 мм/сек., длина рулона не менее 50 м
8
Крепление
Возможность жесткого крепления к приборной панели транспортного средства
9
Экран
Встроенный или возможность подключения внешнего экрана
10
Индикация
Наличие звуковой и/или световой индикации (неисправностей)
11
Питание
От бортовой сети автомобиля с автоматическим включением при включении зажигания
диапазон напряжения 9-36 В, защита от скачков напряжения в бортовой электросети
12
Поддержка модулей безопасности
Не менее 1 модуля SAM
13
Навигация
Поддержка встроенного или внешнего приемника GPS или GPS/ГЛОНАСС
14
Диапазон рабочих температур
От -20 до +50 °C
15
Допустимая влажность при работе
Не менее 90% без конденсации

11.4. Требования к стационарным терминалам оплаты (валидаторам).
Валидаторы должны соответствовать требованиям, указанным в таблице № 11.

Таблица № 11

ТРЕБОВАНИЯ К ВАЛИДАТОРАМ


Параметр
Значение
1
Операционная система
Android, Windows, Linux либо другая операционная система реального времени (допускается отсутствие операционной системы при реализации соответствующих программных функций на стационарном терминале водителя)
2
Интерфейсы внешние
CA№ или RS485 или Ethernet 10/100
3
Бесконтактный ридер
Соответствие ISO 14443A & B, ISO 18092
Поддержка протоколов MiFare Classic (1k, 4k), MiFare Plus
Прием карт MasterCard PayPass, VISA PayWave
4
Сканер штрихкодов (в конфигурации для совместной работы с турникетом)
Поддержка 2D штрихкодов, встроенный или внешний
5
Принтер
Встроенный принтер (опционально) с автоматической отрезкой билета, ширина ленты не менее 40 мм со скоростью печати не менее 60 мм/сек., длина рулона не менее 50 м
6
Крепление
Возможность жесткого крепления к вертикальному поручню от 30 до 52 мм диаметром
7
Экран
Не менее 1.5"
8
Звук
Наличие звуковой индикации сигналами различной тональности в случае неисправности с мощностью не менее 1 Вт
9
Питание
От бортовой сети автомобиля
диапазон напряжения 9-36 В, защита от скачков напряжения в бортовой электросети
Потребляемый ток при напряжении сети 24 В - не более 4А
10
Поддержка модулей безопасности
Не менее 1 модуля SAM
11
Диапазон рабочих температур
От -20 до +50 °C
12
Допустимая влажность при работе
Не менее 90% без конденсации

11.5. Требования к терминалам пополнения ЕТК.
Терминалы для пополнения ЕТК за наличный расчет могут быть оборудованы контактным, бесконтактным или обоими типами ридеров.
Для оборудования (ридеров) терминалов пополнения ЕТК за наличный расчет предъявляются требования, указанные в таблице № 12.

Таблица № 12

ТРЕБОВАНИЯ К ТЕРМИНАЛАМ ПОПОЛНЕНИЯ ЕТК


Параметр
Значение
1
Бесконтактный ридер
Соответствие ISO 14443
2
Контактный ридер
Соответствие ISO 7816, EMV L1, L2
3
Поддержка модулей безопасности
Не менее 1 модуля SAM
4
Общие требования
Поддержка протоколов MiFare Classic (1k, 4k), MiFare Plus

11.6. Требования к датчикам мониторинга пассажиропотока.
Оборудование датчиков мониторинга пассажиропотока должно соответствовать требованиям, указанным в таблице № 13.

Таблица № 13

ТРЕБОВАНИЯ К ДАТЧИКАМ МОНИТОРИНГА ПАССАЖИРОПОТОКА


Параметр
Значение
1
Питание
Питание от бортовой сети транспортного средства или встроенного источника питания в течение не менее 1 года
2
Интерфейс
Bluetooth 4.0
3
Возможности настройки
Настраиваемая мощность и частота передачи сигнала, изменяемый UUID
4
Возможности мониторинга
Мониторинг и передача уровня заряда встроенной батареи

11.7. Требования к турникетам.
Оборудование турникетов должно соответствовать требованиям, указанным в таблице № 14.

Таблица № 14

ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ ТУРНИКЕТОВ


Параметр
Значение
1
Тип турникета
Трипод
2
Сканер штрихкодов (в варианте отсутствия сканера на стационарном терминале оплаты)
Поддержка 2D штрихкодов, встроенный или внешний
3
Пропускная способность
Не менее 14 человек в минуту
4
Индикация
Наличие световой и звуковой индикации разрешения и запрета прохода
5
Номинальное напряжение питания
12 или 24 В
6
Диапазон рабочих температур
От -20 до +50 °C
7
Интерфейсы
CA№ или RS485
8
Сертификация
Наличие согласования установки турникета от производителя автобуса
9
Наработка на отказ, проходов
Не менее 1000000
10
Срок эксплуатации
Не менее 8 лет

12. Схемы оснащения транспортных средств терминалами оплаты

12.1. Типовая конфигурация № 1.

Таблица № 15

ОПИСАНИЕ ТИПОВОЙ КОНФИГУРАЦИИ № 1 ДЛЯ ВСЕХ ВИДОВ АВТОБУСОВ


Параметр
Значение
1
Виды автобусов
МВ, БВ, ОБВ, СВ
2
Схема обслуживания пассажиров
Вход и выход через все двери одновременно
3
Продажа разовых билетов за наличный расчет
Кондуктор (Стюарт) с помощью мобильного терминала оплаты проезда
4
Прием социальных карт, ЕТК и банковских карт
Кондуктор (Стюарт) с помощью мобильного терминала оплаты проезда
5
Контроль оплаты проезда
Контролер с помощью мобильного терминала контроля оплаты проезда
6
Стационарное оборудование на автобусе
1 (МВ, СВ) или 2 (БВ, ОБВ) датчика мониторинга пассажиропотока

12.2. Типовая конфигурация № 2.
Описание оснащения различных классов автобусов в типовой конфигурации № 2 приведено в таблицах № 16-18.

Таблица № 16

ОПИСАНИЕ ТИПОВОЙ КОНФИГУРАЦИИ № 2 ДЛЯ АВТОБУСОВ КЛАССА МВ


Параметр
Значение
1
Виды автобусов
МВ
2
Схема обслуживания пассажиров
Вход и выход через переднюю дверь
3
Продажа разовых билетов за наличный расчет
Водитель с помощью стационарного терминала оплаты проезда
4
Прием социальных карт, ЕТК и банковских карт
Водитель с помощью стационарного терминала оплаты проезда
5
Контроль оплаты проезда
Контролер с помощью мобильного терминала контроля оплаты проезда
6
Стационарное оборудование на автобусе
1 датчик мониторинга пассажиропотока Стационарный терминал водителя Стационарный терминал оплаты проезда

Таблица № 17

ОПИСАНИЕ ТИПОВОЙ КОНФИГУРАЦИИ № 2 ДЛЯ АВТОБУСОВ
КЛАССА СВ И БВ


Параметр
Значение
1
Виды автобусов
БВ, СВ
2
Схема обслуживания пассажиров
Вход через переднюю дверь. Выход через все двери, кроме передней
3
Продажа разовых билетов за наличный расчет
Водитель с помощью стационарного терминала оплаты проезда
4
Прием социальных карт, ЕТК и банковских карт
Стационарный терминал оплаты
5
Контроль оплаты проезда
Контролер с помощью мобильного терминала контроля оплаты проезда
6
Стационарное оборудование на автобусе
1 (СВ) или 2 (БВ) датчика мониторинга пассажиропотока
Турникет
Стационарный терминал водителя
Стационарный терминал оплаты проезда на каждой двери

Таблица № 18

ОПИСАНИЕ ТИПОВОЙ КОНФИГУРАЦИИ № 2 ДЛЯ АВТОБУСОВ КЛАССА ОБВ


Параметр
Значение
1
Виды автобусов
ОБВ
2
Схема обслуживания пассажиров
Вход и выход - все двери одновременно
3
Продажа разовых билетов за наличный расчет
Водитель с помощью стационарного терминала оплаты проезда
4
Прием социальных карт, ЕТК и банковских карт
Стационарный терминал оплаты проезда
5
Контроль оплаты проезда
Контролер с помощью мобильного терминала контроля оплаты проезда
6
Стационарное оборудование на автобусе
2 датчика мониторинга пассажиропотока
Стационарный терминал водителя
Стационарный терминал оплаты проезда на каждой двери

13. Сценарии пополнения, покупки, гашения и проверки
билетов в Системе

13.1. Сценарии покупки и гашения билетов в электронном виде на ЕТК.
13.1.1. Покупка и гашение билета держателем карты ЕТК на первую поездку в течение 30 календарных дней во внутригородском сообщении по полному тарифу на терминалах кондуктора (водителя) и стационарных валидаторах.
Перечень операций:
1. Держатель карты ЕТК прикладывает ЕТК к терминалу.
2. Терминал проверяет принадлежность пассажира к льготной категории.
3. Принадлежность к льготной категории не установлена - выбирается полная тарифная сетка (сценарий по полному тарифу).
4. Терминал по тарифной сетке определяет фиксированный тариф.
5. Терминал записывает на карту реквизиты билета (отметка о гашении).
6. В случае прикладывания карты к валидатору - отправляется команда на открытие турникета.
7. Терминал уменьшает остаток на транспортном кошельке.
8. Терминал отображает сумму поездки и остаток на кошельке.
13.1.2. Покупка и гашение билета держателем карты ЕТК на повторную поездку в течение 30 календарных дней во внутригородском сообщении по полному тарифу на терминалах кондуктора (водителя) и стационарных валидаторах.
Перечень операций:
1. Держатель карты ЕТК прикладывает ЕТК к терминалу.
2. Терминал проверяет принадлежность пассажира к льготной категории.
3. Принадлежность к льготной категории не установлена - выбирается полная тарифная сетка (сценарий по полному тарифу).
4. Терминал по тарифной сетке определяет фиксированный тариф.
5. Терминал в зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
6. Терминал записывает на карту реквизиты билета (отметка о гашении).
7. Терминал уменьшает остаток на транспортном кошельке.
8. Терминал отображает сумму поездки и остаток на кошельке.
13.1.3. Покупка и гашение билета держателем карты ЕТК на первую поездку в течение 30 календарных дней во внутригородском сообщении по льготному тарифу на терминалах кондуктора (водителя) и стационарных валидаторах.
Перечень операций:
1. Держатель карты ЕТК прикладывает ЕТК к терминалу водителя (кондуктора) или стационарному валидатору.
2. Терминал проверяет принадлежность пассажира к льготной категории. В случае принадлежности к льготной категории терминал определяет факт прикладывания карты ЕТК к терминалу того же транспортного средства за последние 10 (настраиваемое значение) минут (необходимо для предотвращения прохода по одной карте ЕТК нескольких человек).
3. Терминал по признаку льготности выбирает льготную тарифную сетку.
4. Терминал по тарифной сетке определяет фиксированный тариф.
5. Терминал записывает на карту реквизиты билета (отметка о гашении).
6. Терминал уменьшает остаток на транспортном кошельке.
7. Терминал отображает сумму поездки и остаток на кошельке.
8. Исключения:
Если установлен факт повторного прикладывания карты ЕТК (с установленной льготной категорией), то:
выводить информацию о повторном прикладывании карты ЕТК с установленной льготной категорией;
запрещать проход;
отправлять информацию о повторной попытке прохода на сервер Системы.
13.1.4. Покупка и гашение билета держателем карты ЕТК на повторную поездку в течение 30 календарных дней во внутригородском сообщении по льготному тарифу на терминалах кондуктора (водителя) и стационарных валидаторах.
Перечень операций:
1. Держатель карты ЕТК прикладывает ЕТК к терминалу водителя (кондуктора) или стационарному валидатору.
2. Терминал проверяет принадлежность пассажира к льготной категории. В случае принадлежности к льготной категории валидатор определяет факт прикладывания карты ЕТК к валидатору того же транспортного средства за последние 10 (настраиваемое значение) минут (необходимо для предотвращения прохода по одной карте ЕТК нескольких человек).
3. Терминал выбирает льготную тарифную сетку.
4. Терминал по тарифной сетке определяет фиксированный тариф.
5. В зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
6. Терминал записывает на карту реквизиты билета (отметка о гашении).
7. Терминал уменьшает остаток на транспортном кошельке.
8. Терминал отображает сумму поездки и остаток на кошельке.
9. Исключения:
Если установлен факт прикладывания карты ЕТК (с установленной льготной категорией), то:
выводить информацию о повторном прикладывании карты ЕТК с установленной льготной категорией;
запрещать проход;
отправлять информацию о повторной попытке прохода на сервер Системы.
13.1.5. Покупка и гашение билета держателем карты ЕТК на первую поездку в течение 30 календарных дней в пригородном сообщении по полному тарифу (предоплаченный билет на терминале водителя (кондуктора), планируемая зона выхода определяется вручную).
Перечень операций:
1. Держатель карты ЕТК сообщает водителю (кондуктору) остановку выхода.
2. Водитель (кондуктор) вводит остановку на терминале.
3. Держатель карты ЕТК прикладывает карту ЕТК к терминалу водителя (кондуктора).
4. Терминал проверяет принадлежность пассажира к льготной категории.
5. Терминал по признаку отсутствия льготности выбирает полную тарифную сетку.
6. Терминал записывает на карту реквизиты билета (отметка о гашении).
7. Терминал уменьшает остаток на транспортном кошельке.
8. Терминал отображает сумму поездки и остаток на кошельке.
13.1.6. Покупка и гашение билета держателем карты ЕТК на первую поездку в течение 30 календарных дней в пригородном сообщении по полному тарифу (билет с автоматической зональной тарификацией по факту поездки на стационарном терминале).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к стационарному валидатору на входе.
2. Терминал проверяет принадлежность пассажира к льготной категории.
3. Терминал по признаку отсутствия льготности выбирает полную тарифную сетку.
4. Терминал рассчитывает максимально возможный тариф от текущей зоны до конца маршрута.
5. Терминал записывает на карту реквизиты билета.
6. Терминал уменьшает остаток на транспортном кошельке.
7. Терминал отображает заблокированную сумму и остаток на кошельке.
8. Держатель карты ЕТК прикладывает карту ЕТК к терминалу на выходе.
9. Терминал по признаку отсутствия льготности на карте ЕТК выбирает полную тарифную сетку.
10. Терминал рассчитывает фактический тариф исходя из зоны входа и зоны выхода.
11. Терминал записывает на карту обновленные реквизиты билета (отметка о гашении).
12. Терминал увеличивает (при разнице между максимальным тарифом и использованным тарифом) остаток на транспортном кошельке.
13. Терминал отображает сумму поездки и остаток на кошельке.
13.1.7. Покупка и гашение билета держателем карты ЕТК на повторную поездку в течение 30 календарных дней в пригородном сообщении по полному тарифу, предоплаченный билет на терминале водителя (кондуктора) (планируемая зона выхода определяется вручную).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к терминалу водителя (кондуктора).
2. Держатель карты вводит на терминале зону выхода из транспортного средства.
3. Терминал проверяет принадлежность пассажира к льготной категории.
4. Терминал по признаку отсутствия льготности выбирает полную тарифную сетку.
5. Терминал в зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
6. Терминал в зависимости от зоны входа и указанной зоны выхода рассчитывает сумму поездки.
7. Терминал записывает на карту реквизиты билета (отметка о гашении).
8. Терминал уменьшает остаток на транспортном кошельке.
9. Терминал отображает сумму поездки и остаток на кошельке.
13.1.8. Покупка и гашение билета держателем карты ЕТК с автоматической зональной тарификацией по факту поездки на стационарном терминале (держатель карты прикладывает ЕТК к стационарному валидатору на входе).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к стационарному валидатору.
2. Терминал проверяет принадлежность пассажира к льготной категории.
3. Валидатор по признаку отсутствия льготности выбирает полную тарифную сетку.
4. Валидатор рассчитывает максимально возможный тариф от текущей зоны до конца маршрута.
5. Валидатор в зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
6. Валидатор записывает на карту реквизиты билета.
7. Терминал уменьшает остаток на транспортном кошельке.
8. Валидатор отображает заблокированную сумму и остаток на кошельке.
9. Держатель карты ЕТК прикладывает карту ЕТК к стационарному валидатору на выходе.
10. Валидатор по признаку отсутствия льготности выбирает полную тарифную сетку.
11. Валидатор рассчитывает фактический тариф исходя из зоны входа и зоны выхода.
12. Валидатор записывает на карту обновленные реквизиты билета (отметка о гашении).
13. Валидатор увеличивает (при разнице между максимальным тарифом и использованным тарифом) остаток на транспортном кошельке.
14. Валидатор отображает сумму поездки и остаток на кошельке.
13.1.9. Покупка и гашение билета держателем карты ЕТК на первую поездку в течение 30 календарных дней в пригородном сообщении по льготному тарифу (предоплаченный билет на терминале водителя (кондуктора), планируемая зона выхода определяется вручную).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к терминалу водителя (кондуктора).
2. Держатель карты вводит на терминале зону выхода из транспортного средства.
3. Терминал проверяет принадлежность пассажира к льготной категории. В случае принадлежности к льготной категории терминал определяет факт прикладывания карты ЕТК к терминалу того же транспортного средства за последние 10 (настраиваемое значение) минут (необходимо для предотвращения прохода по одной карте ЕТК нескольких человек).
4. Терминал по признаку льготности выбирает льготную тарифную сетку.
5. Терминал в зависимости от зоны входа и указанной зоны выхода рассчитывает сумму поездки.
6. Терминал записывает на карту реквизиты билета (отметка о гашении).
7. Терминал уменьшает остаток на транспортном кошельке.
8. Терминал отображает снятую сумму и остаток на кошельке.
9. Исключения:
Если установлен факт прикладывания карты ЕТК (с установленной льготной категорией), то:
выводить информацию о повторном прикладывании карты ЕТК с установленной льготной категорией;
запрещать проход;
отправлять информацию о повторной попытке прохода на сервер Системы.
13.1.10. Покупка и гашение билета держателем карты ЕТК на первую поездку в течение 30 календарных дней в пригородном сообщении по льготному тарифу (билет с автоматической зональной тарификацией по факту поездки на стационарном терминале).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к валидатору.
2. Терминал проверяет принадлежность пассажира к льготной категории. В случае принадлежности к льготной категории валидатор определяет факт прикладывания карты ЕТК к валидатору того же транспортного средства за последние 10 (настраиваемое значение) минут (необходимо для предотвращения прохода по одной карте ЕТК нескольких человек).
3. Валидатор по признаку льготности выбирает льготную тарифную сетку.
4. Валидатор рассчитывает максимально возможный тариф от текущей зоны до конца маршрута.
5. Валидатор записывает на карту реквизиты билета (отметка о гашении).
6. Валидатор уменьшает остаток на транспортном кошельке.
7. Валидатор отображает заблокированную сумму и остаток на кошельке.
8. Держатель карты ЕТК прикладывает карту ЕТК к стационарному валидатору на выходе.
9. Валидатор по признаку льготности выбирает льготную тарифную сетку.
10. Валидатор рассчитывает фактический тариф исходя из зоны входа и зоны выхода.
11. Валидатор записывает на карту обновленные реквизиты билета (отметка о гашении).
12. Валидатор увеличивает (при разнице между максимальным тарифом и использованным тарифом) остаток на транспортном кошельке.
13. Валидатор отображает фактически снятую сумму и остаток на кошельке.
14. Исключения:
Если на ЕТК остаток меньше, чем сумма максимально возможного тарифа от текущей зоны до конца маршрута, то Оператор Системы может принять решение о перевозке пассажира, взяв на себя риски расчета с перевозчиком за данную поездку.
Если установлен факт прикладывания карты ЕТК (с установленной льготной категорией), то:
выводить информацию о повторном прикладывании карты ЕТК с установленной льготной категорией;
запрещать проход;
отправлять информацию о повторной попытке прохода на сервер Системы.
13.1.11. Покупка и гашение билета держателем карты ЕТК на повторную поездку в течение 30 календарных дней в пригородном сообщении по льготному тарифу (предоплаченный билет на терминале водителя (кондуктора), планируемая зона выхода определяется вручную).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к терминалу водителя (кондуктора).
2. Терминал проверяет принадлежность пассажира к льготной категории. В случае принадлежности к льготной категории терминал определяет факт прикладывания карты ЕТК к терминалу того же транспортного средства за последние 10 (настраиваемое значение) минут (необходимо для предотвращения прохода по одной карте ЕТК нескольких человек).
3. Терминал по признаку льготности выбирает льготную тарифную сетку.
4. Терминал в зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
5. Терминал пишет на карту реквизиты билета (отметка о гашении).
6. Терминал уменьшает остаток на транспортном кошельке.
7. Терминал отображает сумму поездки и остаток на кошельке.
8. Исключения:
Если установлен факт прикладывания карты ЕТК (с установленной льготной категорией), то:
выводить информацию о повторном прикладывании карты ЕТК с установленной льготной категорией;
запрещать проход;
отправлять информацию о повторной попытке прохода на сервер Системы.
13.1.12. Покупка и гашение билета держателем карты ЕТК с автоматической зональной тарификацией по льготному тарифу по факту поездки на стационарном терминале (держатель карты прикладывает ЕТК к стационарному валидатору на входе).
Перечень операций:
1. Держатель карты ЕТК прикладывает карту ЕТК к терминалу.
2. Терминал проверяет принадлежность пассажира к льготной категории. В случае принадлежности к льготной категории терминал определяет факт прикладывания карты ЕТК к терминалу того же транспортного средства за последние 10 (настраиваемое значение) минут (необходимо для предотвращения прохода по одной карте ЕТК нескольких человек).
3. Валидатор по признаку льготности выбирает льготную тарифную сетку.
4. Терминал рассчитывает максимально возможный тариф от текущей зоны до конца маршрута.
5. Терминал в зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
6. Терминал записывает на карту реквизиты билета.
7. Терминал уменьшает остаток на транспортном кошельке.
8. Терминал отображает заблокированную сумму и остаток на кошельке.
9. Держатель карты ЕТК прикладывает ЕТК к стационарному валидатору на выходе.
10. Валидатор по признаку льготности выбирает льготную тарифную сетку.
11. Валидатор в зависимости от количества поездок в текущем месяце определяет скидку по тарифной таблице.
12. Валидатор рассчитывает фактический тариф исходя из зоны входа и зоны выхода.
13. Валидатор увеличивает (при разнице между максимальным тарифом и использованным тарифом) остаток на транспортном кошельке.
14. Валидатор записывает на карту обновленные реквизиты билета (отметка о гашении).
15. Валидатор отображает сумму поездки и остаток на кошельке.
Исключения:
Если на ЕТК остаток меньше, чем сумма максимально возможного тарифа от текущей зоны до конца маршрута, то Оператор Системы может принять решение о перевозке пассажира, взяв на себя риски расчета с перевозчиком за данную поездку.
Если установлен факт прикладывания карты ЕТК (с установленной льготной категорией), то:
1. Выводить информацию о повторном прикладывании карты ЕТК с установленной льготной категорией.
2. Запрещать проход.
3. Отправлять информацию о повторной попытке прохода на сервер Системы.
13.1.13. Покупка и гашение пассажиром разовых билетов за наличный расчет (на терминале водителя (кондуктора).
Перечень операций:
1. Пассажир называет конечный пункт.
2. Водитель (кондуктор) выбирает начальный и конечный пункты на терминале и указывает способ оплаты за наличный расчет.
3. Терминал определяет стоимость проезда и выводит стоимость на экран.
4. Пассажир передает водителю (кондуктору) сумму оплаты проезда.
5. Водитель распечатывает билет на терминале и передает его вместе со сдачей (при необходимости) пассажиру.
13.1.14. Покупка и гашение пассажиром разовых билетов с использованием социальной карты.
Перечень операций:
1. Пассажир предъявляет водителю (кондуктору) социальную карту и называет конечный пункт.
2. Водитель (кондуктор) выбирает начальный и конечный пункты на терминале и указывает льготный способ оплаты.
3. Водитель (кондуктор) распечатывает билет на терминале и передает его вместе с социальной картой пассажиру.
13.2. Сценарии пополнения ЕТК.
13.2.1. Пополнение держателем карты ЕТК транспортного приложения ЕТК через платежные киоски с бесконтактным считывателем карт.
Перечень операций:
1. Держатель карты ЕТК вызывает на платежном киоске сервис пополнения карты ЕТК.
2. Платежный киоск предлагает поднести карту ЕТК к считывателю.
3. Держатель карты ЕТК подносит карту к считывателю.
4. Считыватель получает идентификационные данные карты ЕТК.
5. Киоск отображает на экране текущее состояние билета и предлагает выбрать вариант пополнения карты.
6. Держатель карты ЕТК выбирает вариант пополнения, вносит необходимую сумму наличными и вызывает функцию пополнения карты.
7. Платежный киоск осуществляет запись информации о пополнении карты на карту (предложив пользователю приложить карту к считывателю повторно) и на сервер Системы.
Исключения: обрабатываются с помощью организации, обслуживающей платежные киоски.
13.2.2. Пополнение держателем карты ЕТК транспортного приложения ЕТК через банкоматы и платежные киоски, оснащенные контактными считывателями карт.
Перечень операций:
1. Держатель карты ЕТК выполняет авторизацию на банкомате или платежном киоске, если карта имеет банковское приложение.
2. Держатель карты ЕТК вызывает на банкомате сервис пополнения карты ЕТК.
3. Банкомат или платежный киоск предлагает выбрать вариант пополнения.
4. Держатель карты ЕТК вводит сумму пополнения и вызывает функцию пополнения карты.
5. Держатель карты ЕТК оплачивает наличным или безналичным способом сумму пополнения.
6. Банкомат или платежный киоск осуществляет запись информации о пополнении карты ЕТК и на сервер Системы.
7. Исключения:
при ошибке авторизации сценарий прерывается;
при отмене операции сценарий прерывается.
13.2.3. Пополнение держателем карты ЕТК транспортного приложения ЕТК через интернет-сайты (мобильные приложения).
Перечень операций:
1. Держатель карты ЕТК вызывает на интернет-сайте (мобильном приложении) портала сервис пополнения карты с поддержкой MasterCard Moneysend или VISA Money Transfer.
2. Сервис предлагает ввести номер ЕТК.
3. Держатель карты ЕТК вводит номер карты.
4. Сервис проверяет номер, выводит данные держателя карты, запрашивает подтверждение правильности ввода номера карты.
5. Держатель карты ЕТК подтверждает правильность ввода номера карты.
6. Сервис предлагает ввести сумму пополнения.
7. Держатель карты ЕТК вводит сумму пополнения.
8. Держатель карты вводит параметры банковской карты MasterCard или Visa, с которой будет производиться пополнение.
9. Сервис предлагает ввести номер телефона, на который придет СМС-уведомление о поступлении платежа и о доставке информации о платеже во все валидаторы и терминалы оплаты.
10. Информация о платеже отправлена на все валидаторы и терминалы оплаты, пользователь получает СМС с подтверждением о том, что он может использовать свою карту с пополненным балансом на любом валидаторе или терминале оплаты.
11. Пользователь прислоняет карту к ридеру одного из валидаторов или терминалов оплаты, баланс карты пользователя пополняется на сумму пополнения.
12. Информация о том, что карта была пополнена, отправляется на все валидаторы и терминалы оплаты.
13. Исключения:
Ошибка ввода номера карты - уведомление пользователя, сервис предлагает ввести номер и срок действия еще раз.
Остальные исключения обрабатываются с помощью службы поддержки банковской организации.
Примечание: для исключения повторного пополнения карты на сумму пополнения на устройстве, на которое еще не поступила информация о том, что карта пополнена, на карте при ее пополнении должен сохраняться идентификатор, привязанный к операции пополнения карты.

13.2.4. Ввод держателем карты ЕТК параметров автопополнения транспортного приложения ЕТК через платежные киоски с ридером.
Перечень операций:
1. Держатель карты ЕТК вызывает на платежном киоске сервис автопополнения карты ЕТК.
2. Сервис предлагает ввести номер карты.
3. Держатель карты ЕТК вводит номер карты.
4. Сервис проверяет номер и выводит данные держателя карты, запрашивает подтверждение правильности ввода номера карты.
5. Держатель карты ЕТК подтверждает правильность ввода номера карты.
6. Сервис предлагает ввести минимальный остаток на карте и сумму автоматического пополнения.
7. Держатель карты ЕТК вводит минимальный остаток, сумму пополнения и реквизиты банковской карты, с которой будет осуществляться автопополнение, и вызывает функцию сохранения параметров.
8. Сервис сохраняет параметры автопополнения в системе.
9. Исключения:
ошибка ввода номера карты - уведомление пользователя, сервис предлагает ввести номер;
остальные исключения обрабатываются с помощью организации, обслуживающей платежные киоски.
13.2.5. Ввод держателем карты ЕТК параметров автопополнения ЕТК через интернет-сайты (мобильное приложение).
Перечень операций:
1. Держатель карты ЕТК вызывает на интернет-сайте (мобильном приложении) сервис автопополнения карты ЕТК.
2. Сервис предлагает ввести номер ЕТК.
3. Держатель карты ЕТК вводит номер карты.
4. Сервис проверяет номер, выводит данные держателя карты, запрашивает подтверждение правильности ввода номера карты.
5. Держатель карты ЕТК подтверждает правильность ввода номера карты.
6. Сервис предлагает ввести минимальный остаток на карте и сумму автоматического пополнения.
7. Держатель карты ЕТК вводит минимальный остаток и сумму пополнения и вызывает функцию сохранения параметров.
8. Держатель карты вводит параметры банковской карты MasterCard или Visa, с которой будет происходить автоматическое пополнение.
9. Сервис сохраняет параметры автопополнения на сервере Системы.
10. Исключения:
ошибка ввода номера карты - уведомление пользователя, сервис предлагает ввести номер и срок действия еще раз;
остальные исключения обрабатываются с помощью службы поддержки банковской организации.
13.2.6. Автопополнение ЕТК пассажиром при достижении порога автопополнения.
Перечень операций:
1. Сервер Системы проверяет необходимость автопополнения ЕТК каждый раз, когда получает информацию о транзакции по карте, в случае необходимости он передает команду на Сервис автопополнения.
2. Сервис автопополнения осуществляет перевод суммы автопополнения на ЕТК с карты, заданной в параметрах автопополнения, и отправляет информацию во все валидаторы и терминалы оплаты.
Альтернативные сценарии: при отсутствии необходимости автопополнения - выход из сценария.
13.2.7. Пополнение держателем карты ЕТК транспортного приложения ЕТК через СМС.
Перечень операций:
1. Держатель карты ЕТК отправляет с мобильного телефона СМС на короткий номер, в тексте СМС указывает: номер карты и сумму пополнения в рублях.
2. Сервис платежей коротких номеров запрашивает у держателя карты подтверждение списания средств.
3. Держатель карты ЕТК подтверждает использование сервиса.
4. Сервис платежей коротких номеров инициирует зачисление денежных средств на карту.
5. Информация о платеже отправлена во все валидаторы и терминалы оплаты, пользователь получает СМС с подтверждением о том, что он может использовать свою карту с пополненным балансом на любом валидаторе или терминале оплаты.
6. Пользователь прислоняет карту к ридеру одного из валидаторов или терминалов оплаты, баланс карты пользователя пополняется на сумму пополнения.
7. Информация о пополнении карты доставляется из этого устройства на сервер.
8. Исключения:
ошибка ввода номера карты - уведомление пользователя, выход из сценария;
остальные исключения обрабатываются с помощью оператора сотовой связи.
Примечание: для исключения повторного пополнения карты на сумму пополнения на устройстве, на которое еще не поступила информация о том, что карта пополнена, на карте при ее пополнении должны сохраняться идентификаторы, привязанные к операциям пополнения карты.

13.3. Сценарии покупки мобильных билетов.
13.3.1. Покупка билета на разовую поездку с фиксированной тарификацией в электронном виде с оплатой безналичным способом.
1. Пассажир открывает мобильное приложение для приобретения мобильного билета.
2. Если у пользователя включен передатчик Bluetooth и телефон поддерживает протокол Bluetooth 4.0, приложение по технологии Bluetooth сканирует находящиеся поблизости датчики мониторинга пассажиропотока, идентифицирующие транспортное средство.
3. Обнаружив поблизости датчик, приложение с использованием встроенных в ОС средств получает уникальный идентификатор ТС и запрашивает условия тарификации у Системы (модуль тарификации, модуль ведения и синхронизации НСИ).
4. Если у пользователя не включен передатчик Bluetooth или телефон не поддерживает протокол Bluetooth 4.0, приложение предлагает пассажиру ввести уникальный идентификатор ТС или получить его путем сканирования 2D штрихкода с уникальным идентификатором ТС и запрашивает условия тарификации у Системы (модуль тарификации, модуль ведения и синхронизации НСИ).
5. Система по заданному идентификатору возвращает следующую информацию: маршрут, условия тарификации, наименование организации-перевозчика, номер транспортного средства.
6. Приложение отображает информацию, упомянутую в п. 5, и предлагает пассажиру приобрести билет.
7. Пассажир производит оплату любым доступным способом.
8. При успешной оплате мобильное приложение запрашивает из Системы следующие реквизиты билета:
наименование, серия и номер билета;
наименование организации, выдавшей билет;
вид и идентификационный номер транспортного средства, осуществляющего перевозку пассажира;
стоимость билета.
9. Приложение по полученным из Системы данным формирует приобретенный билет и автоматически погашает его.
10. Приложение отображает билет в электронном виде в виде 2D штрихкода для гашения и/или контроля оплаты проезда и в текстовом виде на экране мобильного телефона.
11. Приложение сохраняет билет в локальном хранилище данных для возможности его предъявления контролеру даже при отсутствии связи.
13.3.2. Покупка билета на разовую поездку с зональной тарификацией в электронном виде с оплатой безналичным способом.
1. Пассажир открывает мобильное приложение для приобретения мобильного билета.
2. Если у пользователя включен передатчик Bluetooth и телефон поддерживает протокол Bluetooth 4.0, приложение по технологии Bluetooth сканирует находящиеся поблизости датчики мониторинга пассажиропотока, идентифицирующие транспортное средство.
3. Обнаружив поблизости датчик, приложение с использованием встроенных в ОС средств получает уникальный идентификатор ТС и запрашивает условия тарификации у Системы (модуль тарификации, модуль ведения и синхронизации НСИ).
4. Если у пользователя не включен передатчик Bluetooth или телефон не поддерживает протокол Bluetooth 4.0, приложение предлагает пассажиру ввести уникальный идентификатор ТС или получить его путем сканирования 2D штрихкода с уникальным идентификатором ТС и запрашивает условия тарификации у Системы (модуль тарификации, модуль ведения и синхронизации НСИ).
5. Система по заданному идентификатору возвращает следующую информацию: маршрут, условия тарификации, наименование организации-перевозчика, номер транспортного средства и при возможности остановку посадки пользователя по его местонахождению (по координатам ТС).
6. В случае если остановка посадки не определена, пользователь выбирает ее вручную.
7. В случае если определен маршрут с зональной тарификацией, пользователь выбирает пункт назначения.
8. Приложение рассчитывает стоимость поездки и отображает информацию, упомянутую в п. 5, и предлагает пассажиру приобрести билет.
9. Пассажир производит оплату любым доступным способом.
10. Модуль авторизации снятия денежных средств Системы принимает оплату согласно условиям тарификации.
11. При успешной оплате мобильное приложение запрашивает из Системы следующие реквизиты билета:
наименование, серия и номер билета;
наименование организации, выдавшей билет;
вид и идентификационный номер транспортного средства, осуществляющего перевозку пассажира;
стоимость билета.
12. Приложение по полученным из Системы формирует приобретенный билет и автоматически погашает его.
13. Приложение отображает билет в электронном виде в виде 2D штрихкода для гашения и/или контроля оплаты проезда и в текстовом виде на экране мобильного телефона.
14. Приложение сохраняет билет в локальном хранилище данных для возможности его предъявления контролеру даже при отсутствии связи.
13.3.3. Детектирование сигналов датчиков мониторинга пассажиропотока на транспортном средстве при входе/выходе пассажира из транспортного средства и пересылка данных в Систему.
1. При входе/выходе пассажира из транспортного средства мобильное приложение, установленное на телефоне пассажира, улавливает сигнал Bluetooth датчика-маячка, идентифицирующего транспортное средство.
2. Приложение передает данные об идентификаторе транспортного средства, времени и по возможности геокоординатах пассажира.
3. Система по идентификатору транспортного средства определяет маршрут, организацию-перевозчика, тариф и сохраняет эту информацию (совместно с данными о времени и по возможности геокоординатах пассажира) для последующей аналитической обработки.
4. Исключения:
В случае недоступности связи с Системой приложение накапливает данные в локальное хранилище данных и передает их в Систему при восстановлении соединения.
При отсутствии Bluetooth модуля на мобильном телефоне пассажира и/или выключенном Bluetooth соединении учет данных о входе/выходе из транспортного средства для данного пассажира не производится.
При отсутствии на мобильном телефоне пассажира запущенного мобильного приложения учет данных о входе/выходе из транспортного средства для данного пассажира не производится.
13.4. Сценарии контроля мобильных билетов контролером.
13.4.1. Контроль проездных билетов, приобретенных с помощью мобильного приложения, мобильным терминалом контроля оплаты.
1. Бригадир группы контроля инициирует старт контроля, получая уникальный код ТС от датчиков мониторинга пассажиропотока либо путем ввода в приложение контролера, установленное на мобильном терминале контроля оплаты уникального идентификатора транспортного средства, фиксируя время начала контроля.
2. Приложения контролера на терминалах всей группы контроля автоматически получают введенный бригадиром уникальный код ТС и получают возможность контроля мобильных билетов на данном ТС.
3. Контролер с помощью сканера 2D штрихкодов, встроенного в мобильный терминал контроля оплаты, сканирует предоставленный пассажиром 2D штрихкод.
4. Приложение контролера проверяет полученный от пассажира код билета на валидность и выводит на экран мобильного терминала контроля оплаты информацию о билете:
наименование, серию и номер билета;
наименование организации, выдавшей билет;
вид и идентификационный номер транспортного средства, осуществляющего перевозку пассажира;
дату погашения билета;
срок действия билета;
результат проверки билета.
5. В случае соответствия билета уникальному коду ТС и время начала контроля ТС находится между датами погашения и срока действия билета, такой билет считается валидным, а проезд оплаченным.
6. Информация обо всех проверенных билетах сохраняется в Системе для последующего анализа.
7. В случае отсутствия возможности у пассажира предъявить погашенный билет вследствие каких-либо неисправностей его мобильного телефона пассажир сообщает контролеру номер своего мобильного телефона. Контролер вводит указанный номер в приложение контролера на мобильном терминале контроля оплаты и получает из Системы список погашенных с указанного телефонного номера билетов с неистекшим сроком действия, соответствующих уникальному коду ТС, на котором производится контроль.
13.4.2. Детектирование сигналов датчиков мониторинга пассажиропотока на транспортном средстве при входе/выходе контролера из транспортного средства и пересылка данных в Систему.
1. При входе/выходе контролера из транспортного средства приложение контролера, установленное на мобильном терминале контроля оплаты, улавливает сигнал Bluetooth датчика-маячка, идентифицирующего транспортное средство.
2. Приложение передает данные об идентификаторе транспортного средства, времени и по возможности геокоординатах контролера в Систему.
3. Система по идентификатору транспортного средства определяет маршрут, организацию-перевозчика и сохраняет эту информацию (совместно с данными о времени, идентификаторе контролера и по возможности геокоординатах контролера) для последующей аналитической обработки.
4. Исключения:
В случае недоступности связи с Системой приложение контролера накапливает данные в локальное хранилище данных и передает их в Систему при восстановлении соединения.


------------------------------------------------------------------