Бизнес-архитектура систем взимания платы с автомобилей с использованием данных спутниковой навигации


    Бретонские Bonnets Rouges жгут порталы контроля системы 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 желает, он может сам создать отдел по разбору нарушений, но часто эта функция поручается отдельной специализированной компании, которая собирает данные фото и видео фиксации с контрольных рамок, сверяет нераспознанные номера и формирует документы на взыскание задолженности.

    Роль «Провайдер услуг сбора информации о трафике» включает функции непосредственной эксплуатации порталов контроля. Широка страна моя родная, порталов для нее нужно много, и установлены они будут по всем главным дорогам. Обслуживать все это хозяйство из центра сложно, поэтому логично выделить эти функции в отельную роль, которую могут исполнять несколько компаний по всей стране. Поставлять они будут данные для разбора в едином формате.

    На сегодня у меня все. Не буду заявлять тему следующего материала, так как в последний раз после подобного заявления прошло больше года. Лучше послушаю ваше мнение на этот счет, дорогие хабражители. Тема эта новая, поэтому любая идея может найти свое воплощение. Только еще раз прошу — давайте не будем углубляться в социальную и политическую сферу. Я сам лично за мир во всем мире, бесплатные автобаны без пробок и без ограничений скорости :)
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 18

      +1
      Необходимость данных систем очень сильно надуманна.
      Почему нельзя тот же механизм использовать в цене на топливо?
      Данные системы скорее всего в первую очередь имеют целью мониторинг, кто куда движется и как часто. Очень легко аналитику строить и использовать в разных направлениях.
        +1
        Я не эксперт в экономических оценках, но слежу за обстановкой в отрасли. Так, например, в США, где действует топливный налог, дефицит бюджета на нужды ремонта «интерстетйтов» уже составляет 10 миллиардов долларов в год (!), федеральное агентство усиленно чешет репу и предлагает кабинету Обамы странное. То есть, как минимум для США топливный налог не оправдывает себя. Никаких аналитических выводов делать не буду — это удал профильных спецов.

        Сейчас концепции и проекты подобных систем готовы и в Швеции (Arena) и в Финляндии, в Бельгии вообще внедряют подобную систему для всех транспортных средств, включая легковушки. А уж бельгийцы крутились со своим тендером как никто не крутился, отменяли несколько раз, взбаламутили пол-Европы. Значит, все же рациональные предпосылки есть.
          +1
          Попробую предположить и ответить сам на свой вопрос, что деньги проще направлять, когда они приходят отдельными статьями. А когда собираются финансы в одну точку, — вычленить из них на разные статьи становится невозможным.
          Это как например компенсация льгот для пенсионеров в России была. Или как мучаются в Украине и не платят дотации на отопление, дотации на студентов перевозчикам.
            +1
            Звучит логично, только я не совсем понимаю, какое это имеет отношение к архитектуре системы взимания платы :) В системе каждая транзакция будет снабжена подробнейшей аналитикой, откуда и за что деньги. А как там уж их будут использовать толл чарджеры — их личное дело. СВП ведь могут быть не только федерального уровня, они могут быть введены в отдельных регионах и даже на отдельных дорогах (хотя для спутниковых систем это совсем не характерно, они больше для глобальных регионов делаются).
        0
        Я не эксперт в экономических оценках, но слежу за обстановкой в отрасли. Так, например, в США, где действует топливный налог, дефицит бюджета на нужды ремонта «интерстетйтов» уже составляет 10 миллиардов долларов в год (!), федеральное агентство усиленно чешет репу и предлагает кабинету Обамы странное. То есть, как минимум для США топливный налог не оправдывает себя. Никаких аналитических выводов делать не буду — это удал профильных спецов.

        Сейчас концепции и проекты подобных систем готовы и в Швеции (Arena) и в Финляндии, в Бельгии вообще внедряют подобную систему для всех транспортных средств, включая легковушки. А уж бельгийцы крутились со своим тендером как никто не крутился, отменяли несколько раз, взбаламутили пол-Европы. Значит, все же рациональные предпосылки есть.

          +1
          Маленький комментарий к подписи к КДПВ.

          Не французские, а бретонские. Не реднеки, а современные Bonnets Rouges, там же видно эти самые красные шапочки на фото.
            +1
            Насчет Бретани поправил. Цвет шапочек убрал. А вот «реднеков» оставил, так как по сути верно, под кого бы они не косили. Бучу подняли водители грузовиков из дальних провинций, апеллируя к тому, что им не хочется платить больше налога из-за своей удаленности. Резонные замечания о том, что это налог как раз и введен с целью взимания пропорционального размеру ущерба количества денег, остались не услышанными. Текущая «кусочная» схема даже хуже, чем вообще ничего, так как теперь нужно ждать возмущения более покладистых регионов.
              +2
              Это не «реднеки», что есть по сути — «быдло». Люди борются за свои законные исторические права. Почитайте про историю Бретани, Анну Бретонскую и ее законы о том, что в Бретань свободна от какой либо платы за дороги. Именно поэтому в Бретани нет так называемого «пеяжа» (peage) — то есть платных дорог, которые есть практически повсюду во Франции.
              Сорри за оффтоп.
                +1
                Интересная информация, кстати. Я совершенно не имел до этого представления ни о самом полуострове, ни о его особенностях. Вы меня убедили — уберу «реднеков» с глаз долой. Давно хотел побывать во Франции, но по работе все время отменялись встречи, а для отдыха как-то не получалось.
                  +1
                  А я тут живу, поэтому знаю не понаслышке ) Обращайтесь в личку, если надумаете заехать.
          • UFO just landed and posted this here
              +1
              Желание создать пилотную зону СВП на словах заявляли администрации нескольких регионов. Даже пытались организовать их финансирование :) Но в реальности пока ничего нет кроме слов. Разумеется, следует ожидать большую активность крупных и богатых регионов в этой части. Именно поэтому архитектура будущей СВП должна быть максимально приближенной к стандартам ISO, поскольку стандарты создавались для условий множества участников, включают роуминговые схемы и т.п.
              • UFO just landed and posted this here
                  +1
                  Никому это не понятно. Поэтому сначала нужно обговорить бизнес-схему, а потом уже переходить к технологиям. Пока что понятно, что есть несколько заинтересованных лиц со своими интересами, но синергии у них нет и не будет, так как этой компании нужна воля и участие на уровне государства.
                  • UFO just landed and posted this here
                      +1
                      Пока что идей-то у желающих немного:
                      — А давайте возьмем наши устройства, которые мы делали для проекта А и впарим в проект Б. Не работает из-за специфики требований к устройству.
                      — Мы забацали ЦОД для проекта А, он недозагружен, давайте подключим туда устройства проекта Б через Универсальную Шину Для Подключения Всего (которой еще нет, но при наличии аванса мы начнем ее делать). Уже ближе к теме, но в протоколах обмена тоже полно специфики.
                      — Мы тут с губернатором в бане парились, родилась тема забацать проект Б, разве я не молодец! Баня, конечно, полезна для здоровья, но не настолько же.
                      В проектах данного типа есть объективные и крайне технически рискованные места, и, кстати, это тема для статьи :)
                      • UFO just landed and posted this here

          Only users with full accounts can post comments. Log in, please.