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

    
 Французькі реднекі джгут портали контролю системи Ecotaxe. Фото Europe1.fr
 
З моменту останній публікації на тему систем стягнення плати з використанням супутникового геопозиционирования пройшло більше року. За цей час багато чого змінилося, і змінилося концептуально. Вийшли нові галузеві стандарти, змінилася бізнес-логіка організації збору плати. Так часто трапляється в нових областях. Тому, перш ніж продовжити розповідь про технічні нюанси, хотілося б коротенько розповісти про нову бізнес-моделі і про передумови її появи.
 
 

Історична довідка

У Європі зараз діють всього три повноцінні системи справляння плати на базі даних GPS — у Німеччині (TollCollect ), у Словаччині (SkyToll ) і в Угорщині (Hu-Go ).
 
Німецька система є найстарішою, введена в лад в 2005 році зі значним відставанням від графіка. Система збирає дані на 40 000 км. доріг з 1,5 млн. бортових пристроїв, встановлених на вантажівках. Зараз ведеться розширення системи за охопленням доріг і транспорту інших типів. До слова, 90% прибутку дають якраз користувачі бортових пристроїв, хоча правила передбачають і заявний характер проїзду без бортового обладнання (електронний квиток).
 
Словацька система введена в дію в 2010 році і забезпечує збір даних на 2500 км. доріг з 232000 бортових пристроїв (вантажівки більше 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 бажає, він може сам створити відділ з розбору порушень, але часто ця функція доручається окремої спеціалізованої компанії, яка збирає дані фото і відео фіксації із контрольних рамок, звіряє нерозпізнані номери і формує документи на стягнення заборгованості.
 
Роль «Провайдер послуг збору інформації про трафік» включає функції безпосередньої експлуатації порталів контролю. Широка страна моя родная, порталів для неї потрібно багато, і встановлені вони будуть по всіх головних дорогах. Обслуговувати все це господарство з центру складно, тому логічно виділити ці функції в готельну роль, яку можуть виконувати кілька компаній по всій країні. Постачати вони будуть дані для розбору в єдиному форматі.
 
 На сьогодні у мене все. Не буду заявляти тему наступного матеріалу, так як в останній раз після подібної заяви пройшло більше року. Краще послухаю ваша думка на цей рахунок, дорогі хабражітелі. Тема ця нова, тому будь-яка ідея може знайти своє втілення. Тільки ще раз прошу — давайте не будемо заглиблюватися в соціальну і політичну сферу. Я сам особисто за мир у всьому світі, безкоштовні автобани без пробок і без обмежень швидкості :)
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.