Бизнес-архитектура систем взимания платы с автомобилей с использованием данных спутниковой навигации
Французские реднеки жгут порталы контроля системы Ecotaxe. Фото Europe1.frС момента последней публикации на тему систем взимания платы с использованием спутникового геопозиционирования прошло больше года. За это время многое поменялось, и поменялось концептуально. Вышли новые отраслевые стандарты, изменилась бизнес-логика организации сбора платы. Так часто случается в новых областях. Поэтому, прежде чем продолжить рассказ о технических нюансах, хотелось бы вкратце рассказать о новой бизнес-модели и о предпосылках ее появления.
Историческая справкаВ Европе сейчас действуют всего три полноценные системы взимания платы на базе данных GPS — в Германии (TollCollect), в Словакии (SkyToll) и в Венгрии (Hu-Go).Немецкая система является самой старой, введена в строй в 2005 году со значительным отставанием от графика. Система собирает данные на 40 000 км. дорог с 1,5 млн. бортовых устройств, установленных на грузовиках. Сейчас ведется расширение системы по охвату дорог и транспорта других типов. К слову, 90% прибыли дают как раз пользователи бортовых устройств, хотя правила предусматривают и заявительный характер проезда без бортового оборудования (электронный билет).
Словацкая система введена в строй в 2010 году и обеспечивает сбор данных на 2500 км. дорог с 232 000 бортовых устройств (грузовики больше 3,5 т). В октябре прошлого года электронные билеты были упразднены, и теперь каждый грузовик должен ездить по Словакии с включенным бортовым устройством, которое можно бесплатно получить на границе или в одном из пунктов обслуживания. Сейчас также ведется расширение охвата системы по количеству дорог.
Венгерская система в этой троице самая молодая, введена в строй в июле прошлого года на 6500 км. выбранных местным автодором дорог. Использование бортового устройства в Венгрии не обязательно, основным средством оплаты проезда является покупка «электронного билета», а электронные девайсы введены исключительно для удобства оплаты, так как их использование избавляет от необходимости заранее планировать маршрут и строго его придерживаться.
Для контроля выполнения правил взимания платы на дорогах в специальных местах были установлены порталы контроля, в Германии их 300, в Словакии 46 или около того, а в Венгрии в районе 25-ти. В целях внесения фактора неожиданности по дорогам также перемещаются мобильные аналоги порталов контроля — специально оборудованные фургончики, где-то по одному на каждые 2–3 стационарные опоры, причем в словацком фургончике присутствует местный гаишник с пистолетом, который берет штраф на месте.
Аналогичный по размаху проект создания системы для сбора экологического налога с грузовиков задумывался и во Франции. Но на этапе реализации в августе прошлого года на дороги вышли возмущенные жители Болоньи в оранжевых забавных шапках и принялись жечь и валить дорогостоящее придорожное оборудование. Французское правительство пожало плечами и заморозило проект на год. Сейчас проект снова расчехлили, но уже в порезанном объеме на ограниченном количестве дорог (южные регионы, разумеется, из объемов исключены).
Что касается России, то у нас Росавтодором тоже был объявлен конкурс на создание системы, идеологически подобной словацкой. На момент написания данной заметки судьба конкурса была весьма туманна. Но ясно одно — подобная система в России рано или поздно появится. Мы не будем тут (и в комментариях тоже) обсуждать социальные и экономические аспекты идеи сбора денег на дорогах как таковой, а лучше попробуем сформировать правильный технический взгляд на подходы к решению задач автоматизации подобного класса. Под «правильным» предлагается понимать взгляд, основанный на современном представлении об архитектуре и функциях составных частей системы взимания платы, зафиксированном в европейских стандартах.
Поработаем над архитектурой Начнем мы с определения ролей участников процессов сбора платы. Сразу скажу, что процессы определения ролей устаканивались в ЕС последние пятнадцать лет, и разбор флуктуаций аналитической мысли в этом направлении достоин отдельного поста. Наступив на множество граблей и сломав сотню копий в переговорных баталиях, техническое сообщество таки выработало простую и понятную ролевую модель, отвечающую современным запросам. Как это не смешно звучит, но Европа в настоящее время имеет в сфере систем взимания платы образцово-показательный пример лоскутной автоматизации помноженной на феодальную разобщенность, в свою очередь помноженную на суперпозицию интересов бизнеса, государственных структур и пользователей дорог.Потому неудивительно, что попытки внедрения единой системы, в рамках которой юзер мог бы с одним бортовым устройством проехать по всей Европе, пока что последовательно проваливались. Брюссель регулярно выделяет существенные деньги на решение проблемы интероперабельности, на которые проводят бесконечные пилотные проекты, исписывают тонны бумаги, а воз и ныне там. Только в этом году забрезжил свет в конце тоннеля, профильная комиссия ЕС решилась разрубить гордиев узел весьма неприятным способом — директивно введя то, что не удалось ввести добровольно — те самые стандарты информационного обмена между всеми участниками мытного бизнеса.
Роли в последних версиях стандартов определены на уровне функций:
Toll Charging (TC) — роль «владельца дороги», организации, построившей дорогу или получившей дорогу в управление и намеревающейся драть деньги с проезжающих по дороге авто. Toll Service Provisioning (TSP) — роль непосредственного предоставления услуг сбора платы с использованием средств автоматизации. Тут есть один нюанс (знатоки биллинговых систем не дайте соврать). На западе владелец актива (дороги) очень часто выполняет функции непосредственного расчета тарифа. То есть, между TC и TSP происходит примерно такой диалог: TSP: Смотри, тут юзер проехал 150 километров по платной дороге, вот данные с для тарификацииTC: ОК, вроде все верно. (Звук кассового аппарата). Возьми с него 5 евро, вот данные для счета.TSP: Эй, юзер, гони деньги за проезд, вот тебе счет от хозяина дорогиЗападные люди упорно разносят по разным системам функционал биллинга и функционал CRM, так как владелец ресурса непосредственно участвует в цепочке обработки информации. У нас же в России, наоборот, очень любят объединять под названием «биллинг» в том числе и функции работы с договорами, платежами и даже с абонентским оборудованием. Потому что оператор «биллинга» традиционно обслуживает пользователей и производит расчет тарифа, и ему незачем логически разделять эти функции. В принципе, это не является проблемой, так как объединять сущности легче, чем их разделять.
Но для реального проектирования общефилософских определений недостаточно. Нужно учитывать и нашу местную специфику, и образ мышления наших специалистов. Есть объективная реальность, на которую можно смело опереться при проектировании архитектуры — технологическая цепочка обработки данных спутникового позиционирования для превращения ее в деньги. Вот картинка, которую я передрал из замечательной книги «Road User Charging and Electronic Toll Collection» (ссылка на Amazon)
Этапы обработки данных в СВП на базе данных спутникового позиционирования
Определение местоположения происходит в бортовом устройстве. При этом может происходить сбор дополнительной информации. Часто в БУ устанавливают трехосевой акселерометр, реже гироскоп. Еще реже добавляют возможность подключения к CAN шине автомобиля для снятия данных бортового компьютера. БУ для целей взимания платы водители обычно ставят себе сами (кроме Германии, где это делает авторизованный центр). Поэтому никаких сложных манипуляций при установке не предусматривается — прилепил на лобовое стекло, воткнул в прикуриватель и поехал.
Данные с БУ поступают в фронт-энд систему, главной задачей которой является превращение координатных последовательностей в свидетельства об использовании сегментов платных дорог (а также мостов, тоннелей, переездов и проч.). Треки могут привязываться к ребрам дорожного графа, как это делают бытовые навигаторы, или же решение об использовании сегмента может приниматься на основании факта прохождения автомобиля через определенную область (виртуальный шлюз). Стоит отдельно отметить, что в Словакии и в Германии первичная обработка треков происходит непосредственно в БУ (т.н. «смарт-БУ»). Современные же архитектуры тяготеют больше к использованию легких БУ, отправляющих только координаты и немного служебной информации, а вся обработка происходит в центральных системах.
Функция анализа маршрута предназначена для того, чтобы скрывать ошибки детектирования сегментов. Например, если мы потеряли трек, или данные пришли недостоверные, то, зная, что телепорт пока не изобретен, можно достроить маршрут по имеющимся точкам и по-тихому добавить пользователю в счет. Разумеется, подобные аналитические данные имеют особую отметку для биллинга и оцениваются по отдельным KPI.
Данные об использовании упрощенно представляют собой идентификаторы сегментов, привязанных к идентификатору автомобиля. Обрабатываются они в биллинговой системе аналогично данным об использовании коммуникационных услуг. В принципе, в этой части можно смело использовать бизнес-модель eTom. Каждый сегмент связан с тарифом, есть модификаторы по времени, классу автомобиля и т.п.
На следующей картинке показаны европейские стандарты, используемые на каждом из этапов обработки информации, на которые можно опираться при проектировании СВП.
Процесс обработки информации об использовании платной дороги
Как видно, стандартизирована только центральная, технологическая часть цепочки. Формат данных, поступающих от БУ на фронт-энд систему не стандартизирован. В Европе традиционно эта часть отдана на откуп поставщикам БУ, которые используют собственные протоколы и часто поставляют комплект из БУ и соответствующего фронт-энда. Думаю, стандартизация интерфейсов в этой части еще предстоит.
Немного по сущностям.
Charge Report — структура данных в стандартном формате, передаваемая от фронт-энда, содержащая информацию об использованных дорожных сегментах и сопутствующую информацию. Toll Declaration — регулярно формируемый TSP документ установленного вида на основании Charge Report, содержащий информацию, необходимую TC для расчета суммы тарифа. Элемент официального документооборота между TSP и TC (не типичен для РФ). В западных бизнес-схемах часто функция расчета тарифа выполняется непосредственно на уровне TC. TSP готовит данные для расчета тарифа, на их основании TC производит расчет суммы тарифа, после чего возвращает ее в виде официального документа TSP, который на ее основании выставляет пользователю счет. Billing Detail — набор данных, необходимый и достаточный для определения суммы счета на стороне TC. Payment Claim — регулярно формируемый TC на основании Billing Detail документ, содержащий сумму платежа. Аналогично Toll Declaration, только в обратную сторону — от TC в сторону TSP Схема взаимодействия между ролями получилась довольно простой и логичной, что позволило разработать и применить стандарты измерения бизнес-KPI всего процесса взимания платы, как сквозные (end-to-end), так и для каждого шага в отдельности (см. ISO 17444).Вокруг базового процесса взимания платы выстраивается архитектура СВП в целом, описанная в ISO 17573. Когда я попытался приземлить теорию в нашу местную реальность, у меня получилась следующая картинка:
Схема информационного взаимодействия участников процесса взимания платы
Уровень Provision я разделил на непосредственно TSP = «Оператор СВП» и на отдельную роль «Провайдер услуг сбора информации БУ». Разделение носит принципиальный характер, так как мне кажется логичным разделить функции обслуживания пользователей (персональные данные!) и функции сбора телематики БУ. Тем более, что поставщиков БУ может быть множество. В той же Венгрии, к примеру, действует около 20 поставщиков БУ, у каждого из которых своя система обработки данных. Все они генерируют стандартизованные отчеты об использовании (Toll Declaration), которые уже обрабатываются в единой государственной системе.
Уровень Charging представлен тремя ролями. «Оператор платной дороги» это TC (Toll Charger). У нас в РФ функции TC в части СВП сводятся к финансовому контролю, формированию правил взимания платы и к непосредственному контролю их исполнения.
Функция анализа данных контроля вынесена в отдельную роль «Оператор системы контроля оплаты». Если TC желает, он может сам создать отдел по разбору нарушений, но часто эта функция поручается отдельной специализированной компании, которая собирает данные фото и видео фиксации с контрольных рамок, сверяет нераспознанные номера и формирует документы на взыскание задолженности.
Роль «Провайдер услуг сбора информации о трафике» включает функции непосредственной эксплуатации порталов контроля. Широка страна моя родная, порталов для нее нужно много, и установлены они будут по всем главным дорогам. Обслуживать все это хозяйство из центра сложно, поэтому логично выделить эти функции в отельную роль, которую могут исполнять несколько компаний по всей стране. Поставлять они будут данные для разбора в едином формате.
На сегодня у меня все. Не буду заявлять тему следующего материала, так как в последний раз после подобного заявления прошло больше года. Лучше послушаю ваше мнение на этот счет, дорогие хабражители. Тема эта новая, поэтому любая идея может найти свое воплощение. Только еще раз прошу — давайте не будем углубляться в социальную и политическую сферу. Я сам лично за мир во всем мире, бесплатные автобаны без пробок и без ограничений скорости :)
