На сегодня у нас намечена экскурсия на передний край практических технологий взимания платы за проезд по автомобильным дорогам на основе спутниковой навигации. Несмотря на кажущуюся простоту вопроса, для настоящего понимания данной темы с ракурса системной архитектуры необходимо уяснить некоторое количество концептуальных положений. Большая их часть выработана международным сообществом путем хождения по техническим граблям, включая как неудачные «пилоты», так и проваленные «взрослые» проекты с многомиллионными бюджетами. Некоторые проекты провалились по политическим причинам, но в каждом провале, независимо от того, откуда был нанесен последний фатальный удар, присутствует изрядная порция технических ошибок. А мы с вами, коллеги, прекрасно понимаем, что честная информация об ошибке стоит десяти рапортов об успехах. Начнем мы с краткого описания технологии, потом в следующих частях перейдем к информационным потокам и стандартам, а закончим традиционными проектными сплетнями.
Суть технологии заключается в сборе информации о движении транспортных средств при помощи специализированных бортовых устройств, анализе этой информации и расчете платы за проезд по платным участкам дорог.
Часто для целей контроля за процессом взимания платы на дороге устанавливается специальное оборудование – система стационарного контроля (ССК), технически идентичное оборудованию MLFF, описанному в предыдущей статье.
Роли участников процесса сбора платы и основные бизнес-процессы СВП
Западный функционально-ориентированный подход, который я подробно описал ранее, требует начать проектирование архитектуры системы с базовых бизнес-процессов, от которых мы плавно переходим к функциям, а от функций – к техническим решениям.
Обобщение опыта и анализ существующих проектов привели к появлению ряда бизнес-моделей, которые так или иначе описывают взаимоотношения всех участников. В данной статье предлагаю ограничиться европейским опытом.
Модель CESARE, разрабатываемая ASECAP (сообщество операторов платных дорог и производителей оборудования для них) при содействии Европейского Союза, предназначена для развития и внедрения единых подходов к сбору платы для всех участников рынка платных автомагистралей.
Альтернативная модель "GNSS enabled Services Convergence (GSC)" продвигается рядом крупнейших участников европейского рынка оборудования и ПО при активном содействии Европейского Союза и предназначена для выработки единых архитектурных подходов при построении систем сбора платы на основе GNSS и EGNOS (европейская система по улучшению точности GPS).
Роли в модели CESARE
Модель СESARE предполагает три основные роли:
- Пользователь (Service User) – владелец транспортного средства, зарегистрированный в СВП.
- Оператор СВП (Toll Charger) – отвечает за осуществление корректных расчетов с Пользователями.
- Провайдер СВП (Service Provider) – отвечает за информационное и техническое обеспечение Оператора посредством одного или нескольких Соглашений об уровне сервиса (SLA).
На схеме есть еще и четвертая роль — Interoperability Manager, обеспечивающий технологическую совместимость различных СВП, а также предоставляющий услуги клиринга при взаиморасчетах между операторами. Данная роль характерна для Европы, где СВП развивались параллельно, и вопрос интеграции стоит давно и крайне серьезно. Я очень надеюсь, что нам удастся избежать необходимости создания подобных сложных схем.
Провайдер СВП является владельцем Платформы — аппаратно-программного комплекса, который является средством реализации сервисов.
Также Провайдер реализует ряд бизнес-процессов, которые можно разделить на три типа:
- Коммерческие процессы – контакт с пользователем, выставление счетов, логистика бортовых устройств и т.п. В целом, модель бизнес-процессов коммерческого блока очень похожа на телекомовский eTOM. Но я, тем не менее, не советовал бы заимствовать эту модель напрямую. Для нужд СВП она слишком избыточна и одновременно с этим не учитывает ряд важнейших нюансов (о которых можно говорить много и отдельно). Когда на нашего брата-интегратора падает заказ на СВП, то его специалисты (как правило, подкованные в телеком) тут же берут модель eTOM и средства автоматизации из смежных проектов (какой-нибудь биллинг с барского плеча, или, что еще хуже, коробочного монстра от крупного вендора). Для втюхивания проекта недалекому заказчику и распила бюджета это вполне прокатит. Но если вам нужно честно построить работающий бизнес, забудьте о телеком! Этот опыт вам несомненно пригодится, но его нужно значительно обогатить для данной сферы.
- Операционные (технологические) процессы – сбор и выверка информации об использовании платных дорог, расчет тарифа, контроль фрода и т.п. специфичные для данного бизнеса процессы. На них мы остановимся подробно ниже по тексту.
- Технические процессы эксплуатации, общие для любого ИТ-хозяйства: блок «классических» процессов ITSM, включая управление регламентными работами, ряд специфичных процессов по обеспечению безопасности ремонтных работ на дороге и т.п.
Немного о бортовых устройствах
Бортовое устройство, используемое в Словакии
Основой для выставления счета пользователю является установленный факт использования платной дороги (или ее элемента). Аналогичную функцию в телеком выполняет модуль предбиллинга, собирающий разнородную информацию об использовании оборудования связи.
Информацию об использовании дорог поставляют бортовые устройства, устанавливаемые на автомобили. До недавнего времени это были отдельные «коробочки», крепящиеся к лобовому стеклу автомобиля, сейчас начали серьезно говорить об использовании в роли БУ обычных смартфонов с навигацией и соответствующим приложением.
Алгоритмы вычисления факта использования бывают различные. Например:
- Автомобиль проехал определенное количество километров по платному сегменты – выставляется счет за пройденное расстояние.
- Автомобиль проехал больше половины платного сегмента – выставляется счет за сегмент платной дороги.
- Автомобиль проехал через выделенную область на платном сегменте (контрольную точку) – выставляется счет за весь сегмент.
- Автомобиль проехал через две области – «въездную» и «выездную». Счет выставляется как за проезд по классическому закрытому участку платной дороги.
Источником данных для расчета факта использования являются координаты GPS или ГЛОНАСС.
Если БУ передает эти координаты через сотовую сеть в центральную систему, где происходит расчет фактов использования, то такое БУ называется «тонким». Оно дешево, но при этом генерирует большой трафик и не слишком пригодно для условий плохого покрытия сотовой связью.
Если БУ само определяет факты использования и передает в центральную систему не координаты, а, к примеру, идентификаторы пройденных сегментов, т такое БУ называется «интеллектуальным». У него повышенные требования к памяти (нужно хранить параметры сегментов или областей детекции), к процессору (нужно обрабатывать координатные последовательности), но оно не так сильно загружает канал и способно значительное время работать автономно.
Но самым приятным бонусом «интеллектуального» клиента является возможность офлайнового получения на месте посредством коротковолновой связи перечня пройденных сегментов – лучшее практическое средство по борьбе с жуликами, позволяющее выпустить на дороги мобильные группы контроля или оснастить считывателями наряды ДПС.
Перенос функций из центральной системы в БУ и обратно позволяет маневрировать в широких диапазонах и гибко подстраиваться под возможности и цены местных провайдеров связи, под правила взимания платы, под локальные законы о защите персональных данных и т.п.
Например, в Германии автомобилист может продолжать движение, если его не уведомили о низком балансе на счете. Поэтому БУ в Германии умеет считать баланс – вместе с идентификаторами сегментов в его память загружается актуальная таблица тарифов.
Бортовое устройство для взимания экологического налога с грузовиков в Германии
В Словении суровые законы о защите ПД, к которым относится любая информация о передвижении, поэтому бортовое устройство там может отправлять в центр только сумму на списание и некий идентификатор абонента, никаких сегментов, треков, имен и фамилий!
Бортовое устройство, которое планировалось использовать в Словении. Дальше пилота дело не пошло.
Во Франции запрещено передавать координаты вне платных дорог, поэтому, несмотря на то, что они выбрали модель «тонкого» БУ, которое гонит координаты для обработки в центр, в памяти БУ хранится граф платных дорог, при съезде с которых отправка потока координат в центр тут же прекращается.
Бортовое устройство для взимания экологического налога во Франции
В Новой Зеландии платные вообще все дороги, но автомобилисты не всегда ими пользуются, и государство обязано делать вычет за проезд по целине. До недавнего времени они там использовали механические счетчика на колесах (хубометры), но постепенно стали переходить на бортовые устройства, которые аккуратно считают проезд именно по дорогам и не считают проезд по полям.
Новая Зеландия. Механический хубометр (продвинутая модель).
Новая Зеландия. БУ для замены механического хубометра.
То есть, нюансов по разным странам множество, как и архитектурных решений.
По части железа также существуют варианты исполнения. Кто-то делает легкие и производительные устройства с программированием на C и C++, кто-то использует более тяжеловесные Java – процессоры. В последнее время усилилось влияние интегрированных решений на одном чипе, таких как NXP ATOP, когда в крохотный корпус втискивается JVM, память, три процессора, модуль безопасности, GSM модем, GPS приемник и куча интерфейсов, включая автомобильный CAN.
Внешний вид чипа NXP ATOP
Архитектура NXP Atop (источник)
Во второй части статьи будет рассматриваться комплекс стандартов и общие подходы к организации информационного обмена между элементами телематической платформы СВП.
Автор: drosselmayer
