На московском транспорте грядёт революция, пожалуй, не менее значимая, чем МЦД или БКЛ, революция и имя ей - Новая Билетная Система (НБС). Документ большой, но постарался резюмировать новинки. Итак, что мы увидим нового:
1. Первое и главное, без которого всё остальное не имеет смысла (агенты и контрагенты продаж, сторонние перевозчики и клиенты, взаимное признание билетов и черных списков билетных систем других регионов), масштабирование:
Техническая архитектура Билетной системы должна строиться по следующим принципам:
- модульный принцип построения, обеспечивающий возможность добавления/изменения/замены/удаления модулей без необходимости изменения архитектуры в целом, в том числе архитектура Системы должна предусматривать независимую работу программных компонентов бизнес-логики и технических программных компонентов;
- масштабирование в заданном диапазоне количественных параметров системы должно осуществляться за счет увеличения вычислительных средств, без модернизации самой системы. Подключение устройств пассажирской автоматики, с которыми работает система, и увеличение количества используемых в системе билетных носителей не должно приводить к необходимости модернизации системы и должно обеспечиваться только увеличением производительности технических средств, на которых развернута система;
Если бы не это требование, то НБС не отличалось бы от многих подобных (и даже безымянных) систем. И, как следствие, система предлагается для взаимодействия с другими клиентами (для оплаты услуг), регионами и сторонними перевозчиками:
Возможности интеграции (взаимного признания Электронных кошельков пассажира и возможность записи сторонних билетов на карту «Тройка») с билетными системами других регионов Российской Федерации;
Возможность массового использования новых каналов продаж, способов оплаты, видов носителей, в т.ч. мобильных устройств;
Подсистема должна обеспечивать возможность обмена следующими данными с информационными системами перевозчиков других регионов.
Входные потоки:
- Данные о поездках в транспортных средствах перевозчиков других регионов за счет Баланса.
- Выходные потоки:
- Данные об оформлении продуктов сторонних перевозчиков с использованием каналов продаж Системы.
Городской сервис
Организация или предприятие независимо от организационно-правовых форм или индивидуальный предприниматель, осуществляющий продажу товаров и/или предоставляющий услуги, не относящиеся к Услугам перевозки Пула Перевозчиков, а именно: услуги транспорта (каршеринг, велопрокат, такси), услуги Сторонних Перевозчиков, обеспечение возможности совершения покупок в точках продаж, расположенных на территории, подконтрольной перевозчикам или оператору билетной системы, а также предоставление прочих городских услуг (сервисов) – музеи, парки, катки, аквариум, экскурсии, кино и иные)
Рисунок 11. Логическая архитектура НБС (1499x977; 257.82 килобайт)
2. Комбинированный режим (онлайн/оффлайн), и для этого вводится градации устойчивости связи
Рисунок 2. Градации устойчивости связи у пользователей НБС (1514x696; 105.82 килобайт)
НБС должна обеспечить поддержку нескольких режимов работы пассажирской автоматики, в зависимости от наличия связи:
- Онлайн: между пассажирской автоматикой и централизованными компонентами есть качественная связь. Пополнение или принятие решения о возможности оказания услуги перевозки осуществляется в компонентах 1-го уровня (устойчивая связь: мосметро);
- Офлайн: пассажирская автоматика в момент использования билета не имеет связи с централизованными компонентами. Пополнение или принятие решения о возможности оказания услуги перевозки осуществляется в компонентах 2-го уровня (проводные сети сторонних операторов) на основании данных, записанных на носитель и данных, хранящихся в компонентах 2-го уровня.
Рисунок 3. Схема работы режима «Гибридный» (739x601; 65.11 килобайт)
«Гибридный» (предлагаемый вариант)
Где хранится информация о балансе: Мастер баланс и билеты – в ядре Системы; Реплика баланса и билетов – на носителе
Как организована валидация: Валидатор считывает информацию на носителе и передает ее в ядро Системы, которое принимает решение о пропуске; В случае потери связи, решение о пропуске принимается на Валидаторе после проверки по стоп-листам и данным, записанным на носитель; При проходе валидатор изменяет на носителе информацию о балансе и билетах;
При восстановлении связи с ядром информация о балансах и билетах синхронизуется с ядром Системы
3. Поддержка зональной тарификации, и вызванные этим очень специфические требования к Устройствам Пассажирской Автоматики (УПА):
В 2012 году территория Москвы увеличилась в 2.5 раза, в связи с этим расширилась зона действия московского общественного транспорта и возникла необходимость ввода тарифных зон, но существующие билетные системы не поддерживают зональную тарификацию.
При проектировании в НБС должна быть заложена поддержка функционала зональной тарификации, в том числе должны быть разработаны инструменты управления моделью пересадок и тарифов НБС, позволяющие добавлять новые правила тарификации проезда с учетом поддержки зональности с требуемой логикой обработки проходов.
ФТ_ТОП.07
Турникет вестибюльного комплекса должен поддерживать функции:
Открытие створок на вход;
Открытие створок на выход;
Фиксация входа;
Фиксация выхода
ФТ_ТОП.08
Турникет наземного транспорта должен поддерживать функции:
Открытие на вход;
Открытие на выход;
Фиксация входа;
Фиксация выхода
Странным выглядит для Москвы требование для Переносных Устройств Контролёра:
4.2.1.3.3 ПУсК
ПУсК должно поддерживать следующие режимы работы:
ФТ_ПСК.1
Режим контроля: осуществляется проверка валидности билетов и носителей, проверка фактов прохода с использованием билетов и носителей
ФТ_ПСК.2
Режим валидации: осуществляется валидация разовых билетов (Билет помечается на носителе как использованный), списание поездок с абонементов «на N поездок», оплата совершаемой поездки с использованием Баланса и банковских карт, проставляется метка прохода
Впрочем, в пояснительных записках к техзаданию, поднимается вопрос об избыточности функционала режима валидации на ПУсК в Москве, на что дан был ответ о том, что билетное решение разрабатывается не только для Москвы. Осталось неясным касается то же самое турникетов на выход, особенно после такой преамбулы про расширение города, и необходимости зональной системы.
4. Увидим некоторое разнообразие повременных билетов, и овердрафт 'Электронного Кошелькаf'
Перечень продуктов, поддержка которых должна быть реализована в НБС, можно разделить на несколько основных типов (список продуктов может быть расширен):
Таблица 10 – Типы продуктов
Тип продукта
Билет на «N поездок» с ограничением срока действия
Билет на «X минут» на «N поездок» с ограничением срока действия
Разовый билет
Разовый билет «X минут»
Билет, приобретаемый на турникете
Абонемент на период
Билет «Кошелек»/Электронный кошелек пассажира
Постоплатные билеты (в том числе: льготные, ВЛБ, БОП)
Зональный билет (зона задается на виды транспорта, станциями и т.д.)
Так же в тариф "Электронный кошелёк" подвергнется уточнению, возможному разрешению некоего овердрафта:
31. Лимиты на расходы в режиме офлайн
При гибридном режиме взаимодействии (онлайн/офлайн) носителей с НБС для продукта должен задаваться доступный лимит на расход баланса билета в режиме офлайн (при не синхронизированном балансе с ядром НБС)
А так же определение персонификации билета
32. Обязательность привязки носителя
Признак обязательности (да/нет) привязки носителя продукта к ЛК пассажира.
5. Необязательная персонификация пассажира
В настоящий момент все пассажиры обезличены и в билетной системе неотличимы друг от друга.
С точки зрения пассажиров отсутствие идентификации не позволяет предоставлять им ряд востребованных услуг:
- Доступ в Личный кабинет;
- Восстановление билетов с утерянных носителей;
- Персонализированные коммуникации.
С точки зрения городской инфраструктуры усложнены коммуникации с пассажирами, не хватает детальной информации о транспортном поведении жителей, что сильно усложняет или делает невозможным оперативное предоставление пассажирам актуальной информации о транспортной ситуации, альтернативных маршрутах, сбор и обработку обратной связи, предложение бонусов и стимулирование пользования общественным транспортом.
В целях устранения описанных недостатков в Системе должны быть предусмотрены возможности расширенной идентификации пассажиров.
Регистрация выполняется удаленно и предполагает привязку к билетному носителю следующих данных, по которым пассажира можно авторизовать:
- Имя учетной записи пользователя (логин);
- E-mail;
- Учетная запись Системы управления доступом к информационным системам и ресурсам города Москвы (далее СУДИР);
- Номер мобильного телефона.
Зарегистрированный пассажир имеет возможность:
- Связать с пассажиром несколько билетных носителей;
- Пользоваться Личным кабинетом, в том числе посмотреть баланс, остаток билетов, историю поездок, блокировать принадлежащие ему носители в случае утраты/поломки, переносить неиспользованные остатки продукта/билета на другие носители и т.п.;
- Получать различные уведомления на зарегистрированный e-mail или мобильный номер
- Для возможности зарегистрированным пассажирам пользоваться Личным кабинетом необходимо в Системе задать логин и пароль.
- В Системе должна быть предусмотрена возможность регистрации и управления приведенными выше атрибутами (имя учетной записи пользователя, email, номер телефона, пароль).
В Системе не хранятся персональные данные пассажиров.
6. НБС предусмотрены Личные Кабинеты разных категорий пользователей (эмитентов, контрагентов, продавцов и.т.д)
В отличие от пассажиров необходимым условием организации подключения к Системе остальных категорий пользователей Системы (КК, внутренних пользователей, внешних контрагентов) является их обязательная регистрация в Системе, а также ведение и хранение о них дополнительной информации, необходимой для обеспечения их взаимодействия с Системой.
- В Системе должны быть зарегистрированы как непосредственно организации-потребители услуг, так и все пользователи-сотрудники данных организаций в привязке к самим организациям.
- Система должна позволять для каждой организации-пользователя задать перечень внутренних структурных подразделений, сотрудники которых могут иметь доступ к Системе. Каждому структурному подразделению каждой организации-пользователя должна быть сопоставлена бизнес-роль, определяющая и задающая права доступа в Системе. При этом каждое физическое лицо должно получить отдельное регистрационное имя (учетную запись), пароль доступа и права доступа соответствующей бизнес-роли.
- Кроме учетных данных физических лиц в Системе должна быть предусмотрена возможность ведения учетных данных служебных технологических пользователей, предназначенных для организации автоматизированного взаимодействия между внутренними компонентами Системы, а также для интеграции НБС с внешними и смежными системами.
- Все технологические учетные записи должны быть также привязаны к технологическим бизнес-ролям, а также иметь отдельные регистрационные имена и пароли доступа.
- Система должна иметь возможность ведения учетных записей для каждой категории пользователей с сохранением истории всех изменений.
7. Возможности биллинга, постоплата, расчёт тарифов, перерасчёт скидок
По факту регистрации в Системе транзакций функция биллинга должна:
- Учитывать факты оплат и пополнений;
- Учитывать объемы оказанных услуг перевозки и услуг городских сервисов;
- Контролировать и формировать списания за оказанные услуги;
- Рассчитывать и применять скидки;
- Учитывать корректировки платежей и списаний;
- Осуществлять квитовку услуг и платежей (контроль покрытия списаний платежами);
- Поддерживать предоплатные и постоплатные режимы расчетов за услуги;
- Выставлять ежемесячные и внеочередные счета на оплату пассажирам и -корпоративным клиентам;
- Контролировать предоставление услуг в зависимости от статуса оплаты счета.
В Системе должны быть также поддержаны следующие возможности:
- Работа с любым количеством продуктов, заданных в продуктовом каталоге;
- Тарификация услуг по алгоритмам, заданным в настройках продуктов;
- Дотарификация в случаях:
- Использования тарификационных моделей, не реализуемых в офлайн;
- Запаздывания доставки транзакций до ядра Системы;
- Перетарификация в случаях выявления ошибок тарификации и необходимости пересчета после исправления;
- Управление операционным и отчетным периодами.
8. Вероятность того, что новые билеты НБС будут несовместимы с нынешними билетами
Состав Битмапа должен быть уточнен на этапе технического проектирования Системы.
А разделе "5.1.4 Этап 4. Поддержка полного функционала НБС, развертывание ограниченного полигона НБС по другим перевозчикам.", видно, что наравне со новыми (прошедшими апгрейд устройствами АСОП-АСКП) Устройствами Пассажирской Автоматики, каке-то время должны будут сохраняться и старые, но об этом ниже
9. Будут отдельные операции как для носителя в целом, так и для отдельных билетов на нём (черные и белые списки, хант-листы - билеты требующие усиленной проверки, и сработки световой и звуковой сигнализации на валидаторах)
10. Ну и сроки внедрения НБС, за спойлерами схематическая рисунки архитектуры НБС (бирюзовым цветом), с постепенным изъятием частей АСОП-АСКП (оранжевым цветом), на каждом этапе:
Этап 1. Разработка - 182 календарных дня (срок окончания: середина лета 2019)
Этап 2. Создание прототипа НБС, реализация начального функционала НБС - поддержка привязки Тройки к номеру мобильного телефона - 397 календарных дней со дня заключения контракта (предположительно, февраль- март 2020)
Открыть в полном размере (869x726; 72.38 килобайт)
Этап 3. Поддержка базового функционала НБС, апробация новых образцов Устройств Пассажирской Автоматики (в Мосметро, МЦК, ММТС), Срок окончания (в календарных сутках): 182 (1й этап разработки) + 550 (3й этап), то есть примерно, предположительно, к окончанию 2020 года
Открыть в полном размере (965x838; 86.85 килобайт)
Этап 4. Поддержка полного функционала НБС на Мосметро, МЦК, ММТС и пробная эксплуатация на транспортных средствах НГПТ, срок - 178 дней со дня завершения "Этап 3", то есть, полное завершение перехода с АСОП-АСКП на НБС должно, предположительно, состояться в середине 2021.
Открыть в полном размере (964x746; 80.86 килобайт)
Сроки, естественно, могут сдвинуться, как в ту, так и в иную сторону...
Ну, и, наверное, следует упомянуть об итогах тендера:
Открыть в полном размере (906x344; 60.12 килобайт)
Гугл находит статью на cnews: В России появилась билетная система нового поколения (это имеется про билетную систему ЦППК, если что).
А презентация РЖД своей ЕТК карты, по возможностям слишком похожей, на то, что я тут цитировал, наводит на мысли, что как-то эти события связаны....
2
0 Комментариев
Рекомендуемые комментарии
Комментариев нет