Результат интеллектуальной деятельности: СПОСОБ СВЯЗИ ДЛЯ СИСТЕМЫ СБОРА ОПЛАТЫ, СОДЕРЖАЩЕЙ СЕРВЕР И ПО МЕНЬШЕЙ МЕРЕ ОДНО БОРТОВОЕ УСТРОЙСТВО

Область техники, к которой относится изобретение

Изобретение относится к области применения в автомобильном транспорте. В частности, изобретение относится к способу связи для системы сбора оплаты, соответствующему бортовому устройству и соответствующей системе сбора оплаты, содержащей бортовое устройство.

Уровень техники

В US 2013/0096993 A1 описан способ сбора оплаты с транспортных средств в системе безостановочной оплаты с установленными на транспортных средствах бортовыми устройствами и придорожными радиомаяками. Описанный способ включает в себя этапы, на которых передают информацию о транзакции и параметр с бортового устройства; обновляют параметр в зависимости от переданной информации о транзакции и вычисляют сумму списания в зависимости от обновленного параметра; передают запрос на списание с вычисленной суммой списания и обновленным параметром в бортовое устройство; и списывают принятую сумму списания с кредитного счета оплаты в бортовом устройстве и записывают новую информацию о транзакции относительно этой новой транзакции списания и принятый обновленный параметр в боровом устройстве.

Раскрытие изобретения

Задача изобретения состоит в создании улучшенной системы сбора оплаты.

Данная задача решается признаками независимых пунктов формулы изобретения. Модификации изобретения указаны в зависимых пунктах формулы изобретения и в нижеследующем описании.

Согласно первому аспекту изобретения предложен способ связи для системы сбора оплаты, содержащей сервер и по меньшей мере одно бортовое устройство, причем способ содержит этапы, на которых: задают протокол передачи сообщений, содержащий заданный набор сообщений, подлежащих передаче между сервером и бортовым устройством; инициализируют формат сообщения для каждого из сообщений, причем формат сообщения содержит часть с постоянной длиной и часть с переменной длиной по меньшей мере с одной таблицей состояний; и устанавливают многоуровневую защиту с использованием по меньшей мере двух уровней защиты, присоединяемых к сообщениям и выдаваемых серверу и/или бортовому устройству.

Согласно другому аспекту изобретения предложено бортовое устройство для системы сбора оплаты, причем бортовое устройство содержит: задающий модуль, выполненный с возможностью задания протокола передачи потока сообщений, содержащего заданный набор сообщений; инициализирующий модуль, выполненный с возможностью инициализации формата сообщения для каждого из сообщений, причем формат сообщения содержит часть с постоянной длиной и часть с переменной длиной по меньшей мере с одной таблицей состояний; и устанавливающий модуль, выполненный с возможностью установления многоуровневой защиты с использованием по меньшей мере двух уровней защиты, присоединяемых к сообщениям и выдаваемых серверу и/или бортовому устройству.

Согласно другому аспекту изобретения предложена система сбора оплаты, содержащая сервер и по меньшей мере одно бортовое устройство.

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

Для разработки надлежащего протокола для требований сбора оплаты используется концепция связи и концепция защиты.

Настоящее изобретение с достижением преимущества обеспечивает протокол, который описывает обмен информацией между OBU и сервером связи на основе транспортного протокола TCP/IP. Главное преимущество TCP состоит в том, что он гарантирует доставку передаваемых данных, и отправитель может полагать, что данные доставлены.

В любом случае, когда требуется обратная передача ответного сообщения, отправитель должен установить флаг состояния ожидания до поступления ответа на предыдущий запрос. Если время для состояния ожидания истекает, отправитель может выполнить повторную попытку или отменить запрос. Однако не может быть принято никакое предположение о результате запроса или команды. Число повторных попыток и пороговое значение для отмены запроса зависит от разработчика приложения.

Сообщения не отправляются до тех пор, пока не будет подтверждено прибытие предыдущих сообщений. В противном случае может произойти пересечение подтверждений, приводящее к неясности относительно подтверждения или неподтверждения сообщения.

Кроме того, настоящее изобретение обеспечивает усовершенствованную концепцию защиты. Предложен защищенный механизм передачи данных между OBU и сервером.

Главным образом, для обеспечения защищенного механизма решаются три задачи: целостность, секретность и подлинность.

Согласно примерному варианту выполнения изобретения этап задания протокола передачи сообщений содержит этап, на котором устанавливают флаг состояния ожидания до тех пор, пока не будет принят ответ на предыдущий запрос. Это с достижением преимущества обеспечивает возможность защищенного и отказоустойчивого режима связи.

Согласно примерному варианту выполнения изобретения этап задания протокола передачи сообщений содержит этап, на котором не отправляют сообщения до приема подтверждения приема предыдущего сообщения. Это с достижением преимущества обеспечивает повышенную надежность всей системы.

Согласно примерному варианту выполнения изобретения сообщения передаются посредством системы пакетной радиосвязи общего назначения или другой ориентированной на пакеты мобильной службы передачи данных системы цифровых сотовых сетей, используемой мобильными телефонами. Это с достижением преимущества позволяет использовать уже существующую и установленную сетевую систему.

Согласно примерному варианту выполнения изобретения этап инициализации формата сообщения содержит этап, на котором используют часть с постоянной длиной для определения общей информации для всего обмена данными.

Согласно примерному варианту выполнения изобретения этап инициализации формата сообщения содержит этап, на котором используют часть с переменной длиной для передачи данных, команд и групп запросов.

Согласно примерному варианту выполнения изобретения в качестве заданного набора сообщений используется загрузка микропрограммного обеспечения, поток сообщений по транспортному протоколу TCP, ответ о потерянном подтверждении, дублирование ответа/ACK, инициализация протокола или протокол потерянной обсервации GNSS.

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

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

Согласно другому аспекту изобретения предложен программный элемент, который при его исполнении на одном или нескольких процессорах системы навигации и связи инструктирует систему выполнять этапы способа, описанные выше и ниже.

Согласно другому аспекту изобретения предложен машиночитаемый носитель, на котором сохранен вышеописанный программный элемент.

Машиночитаемый носитель может представлять собой гибкий диск, жесткий диск, CD, DVD, запоминающее устройство USB (универсальной последовательной шины), RAM (запоминающее устройство с произвольной выборкой), ROM (постоянное запоминающее устройство) и EPROM (стираемое программируемое постоянное запоминающее устройство). Машиночитаемый носитель также может представлять собой сеть передачи данных, например Интернет, которая позволяет загружать код программы.

Эти и другие аспекты настоящего изобретения станут более понятными из вариантов выполнения, описанных далее в настоящем документе, и поясняются с обращением к ним.

Теперь ниже будут описаны примерные варианты выполнения настоящего изобретения с обращением к следующим чертежам.

Краткое описание чертежей

На Фиг. 1 показана принципиальная схема системы сбора оплаты, содержащей сервер и три бортовых устройства согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 2 показана принципиальная блок-схема способа связи для системы сбора оплаты согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 3 показана принципиальная блок-схема вычисления CRC согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 4 показана принципиальная блок-схема шифрования согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 5 показана принципиальная блок-схема концепции аутентификации согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 6 показана принципиальная блок-схема инициализации протокола согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 7 показана принципиальная блок-схема протокола загрузки микропрограммного обеспечения согласно примерному варианту выполнения настоящего изобретения;

на Фиг. 8 показана принципиальная блок-схема общего формата усовершенствованной таблицы состояний согласно примерному варианту выполнения настоящего изобретения.

Осуществление изобретения

Иллюстрация на сопровождающих чертежах является схематичной. На различных чертежах аналогичным или одинаковым элементам или этапам присвоены одинаковые ссылочные позиции.

Нижеследующее подробное описание имеет лишь примерный характер и не предназначено для ограничения области применения и использования изобретения.

Кроме того, не подразумевается какое-либо ограничение какими-либо теоретическими сведениями, представленными в вышеприведенном уровне техники или раскрытии изобретения или в нижеследующем подробном описании.

На Фиг. 1 показана принципиальная схема системы сбора оплаты, содержащей сервер и три бортовых устройства согласно примерному варианту выполнения настоящего изобретения.

Система 50 сбора оплаты может содержать сервер 20 и по меньшей мере одно бортовое устройство 10; на Фиг. 1 изображены три бортовых устройства 10, которые размещены на различных транспортных средствах.

Каждое из бортовых устройств 10 может содержать задающий модуль 11, инициализирующий модуль 12 и устанавливающий модуль 13.

Задающий модуль 11 может быть выполнен с возможностью задания протокола передачи потока сообщений, содержащего заданный набор сообщений.

Инициализирующий модуль 12 может быть выполнен с возможностью инициализации формата сообщения для каждого из сообщений, причем формат сообщения содержит часть постоянной длины и часть переменной длины по меньшей мере с одной таблицей состояний.

Устанавливающий модуль 13 может быть выполнен с возможностью установления многоуровневой защиты с использованием по меньшей мере двух уровней защиты, присоединяемых к сообщениям и выдаваемых серверу и/или бортовому устройству.

Бортовое устройство 10 может быть выполнено с возможностью приема навигационных сигналов от навигационного спутника 100. Навигационный спутник 100 может быть придан спутниковой навигационной системе или какой-либо другой системе спутников, которые обеспечивают автономное геопространственное позиционирование с глобальным покрытием.

Бортовое устройство 10 может быть выполнено с возможностью определения своего местоположения (долгота, широта и высота) с высокой точностью (в пределах нескольких метров) с использованием сигналов времени, передаваемых со спутников по радио на линии радиовидимости. Сигналы также позволяют электронным приемникам вычислять текущее местное время с высокой точностью, что обеспечивает возможность временной синхронизации.

Согласно другому варианту выполнения настоящего изобретения таблица состояний представляет собой сообщение, которое несет сформированную или полученную информацию от OBU в сервер. Оно будет отправлено: в качестве ответа на запрос от СЕРВЕРА; при наступлении некоторого события; периодически для целей отслеживания. В общем случае существуют два возможных подхода для этого сообщения:

- постоянная таблица, отправляемая всегда в одном и том же формате вне зависимости от требуемой информации;

- конфигурируемая таблица из заданного списка параметров, которая может быть переконфигурирована, чтобы соответствовать требуемой информации в этот момент.

Первый вариант относится к базовой структуре в форме базовой таблицы состояний. Второй вариант относится к усовершенствованной таблице состояний, например таблице состояний с усовершенствованной структурой данных.

Усовершенствованная таблица состояний имеет следующие характеристики: длину полей и идентификационные коды. Это в общем случае обеспечивает два преимущества:

если приложение не готово к обработке кода поля, оно может игнорировать его и перейти к следующему полю без необходимости обработки неизвестного кода.

Добавление и создание новых полей является более легким. Переменная длина информационных полей может быть включена на основании наступления события.

На Фиг. 2 показана принципиальная блок-схема способа связи для системы сбора оплаты согласно примерному варианту выполнения настоящего изобретения.

Способ связи для системы сбора оплаты, содержащей сервер и по меньшей мере одно бортовое устройство, причем способ содержит следующие этапы:

в качестве первого этапа способа выполняется задание S1 протокола передачи сообщений, содержащего заданный набор сообщений, подлежащих передаче между сервером и бортовым устройством.

В качестве второго этапа способа выполняется инициализация S2 формата сообщения для каждого из сообщений, причем формат сообщения содержит часть с постоянной длиной и часть с переменной длиной по меньшей мере с одной таблицей состояний.

В качестве третьего этапа способа выполняется установление S3 многоуровневой защиты с использованием по меньшей мере двух уровней защиты, присоединяемых к сообщениям и выдаваемых серверу и/или бортовому устройству.

На Фиг. 3 показана принципиальная схема вычисления CRC согласно примерному варианту выполнения настоящего изобретения.

Поскольку протокол связи представляет собой протокол, разработанный для целей сбора оплаты, и работает непосредственно с деньгами, необходима защита связи между OBU и сервером. По этой причине необходимо обеспечить защищенный механизм передачи данных между OBU и сервером.

В общем случае есть три задачи, которые необходимо решить для обеспечения защищенного механизма: целостность, секретность и подлинность.

Целостность будет гарантирована путем вычисления CRC для сообщения или команды и добавления итоговых 2 байтов в конце сообщения/команды, как показано на Фиг. 3.

Контроль циклически избыточным кодом (CRC) представляет собой код для обнаружения ошибок, широко используемый в цифровых сетях и запоминающих устройствах для обнаружения случайных изменений в исходных данных. К блокам данных, поступающим в эти системы, прикрепляют короткое проверочное значение на основании остатка полиномиального деления их содержимого; при извлечении вычисление повторяется, и могут быть предприняты корректирующие действия против предполагаемого повреждения данных, если проверочные значения не совпадают.

CRC называются так потому, что проверочное значение (верификация данных) представляет собой избыточность (она не добавляет информации в сообщение), и алгоритм основан на циклических кодах. CRC просты в реализации в аппаратном обеспечении с двоичной системой исчисления, легко подвергаются математическому анализу и в частности хорошо обнаруживают распространенные ошибки, вызванные шумами в каналах передачи.

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

Используется CRC-16, поскольку особенность данного алгоритма состоит в том, что он будет использовать полином длиной в 17 битов и результат составит 2 байта.

На Фиг. 4 показана принципиальная блок-схема шифрования согласно примерному варианту выполнения настоящего изобретения.

Секретность будет обеспечена путем шифрования нового итогового кадра (заголовок + данные + CRC).

В криптографии шифрование представляет собой процесс кодирования сообщений (или информации) таким образом, чтобы перехватчики или взломщики не могли ее прочитать, а уполномоченные лица могли. В схеме шифрования сообщение или информацию (называемую открытым текстом) шифруют с использованием алгоритма шифрования, превращающего их в нечитаемый шифрованный текст (там же). Обычно это делается с использованием ключа шифрования, который указывает, как должно быть кодировано сообщение.

Любой оппонент, который может видеть шифрованный текст, не должен быть способен определить что-либо в отношении исходного сообщения. Однако уполномоченное лицо способно декодировать шифрованный текст с использованием алгоритма дешифрования, который обычно требует секретного ключа дешифрования, к которому оппоненты не имеют доступа. По техническим причинам схема шифрования обычно требует алгоритма формирования ключей для формирования ключей.

На Фиг. 5 показана принципиальная блок-схема концепции аутентификации согласно примерному варианту выполнения настоящего изобретения.

Поскольку используется шифрование с закрытым ключом, необходим механизм сообщения ключа серверу и OBU, другими словами механизм для того, чтобы OBU аутентифицировало себя на сервере. По этой причине используется кадр, показанный на Фиг. 5.

После шифрования размер шифрованной части известен, поэтому возможно формирование кадра сообщения. Сообщение может иметь следующий формат, как показано на Фиг. 5:

- OBU_ID (13 байтов);

- длина шифрованного сообщения (2 байта);

- шифрованное сообщение.

На Фиг. 6 показана принципиальная блок-схема инициализации протокола согласно примерному варианту выполнения настоящего изобретения.

В начале работы, после того, как на сервере открыт сокет, OBU отправит таблицу состояний, чтобы сигнализировать серверу, что OBU функционирует. До тех пор, пока OBU не получит обсервацию GNSS, оно будет отправлять на сервер только дежурные сообщения (Keep Alive), если у него нет других команд между ними. Когда OBU будет способно получить обсервацию GNSS, оно выдаст серверу другую таблицу состояний, чтобы сигнализировать новое состояние. После этого таблица состояний будет отправляться серверу от OBU в интервале времени отслеживания, и данные позиционирования будут учитываться на стороне сервера.

На Фиг. 7 показана принципиальная блок-схема протокола загрузки микропрограммного обеспечения согласно примерному варианту выполнения изобретения.

После окончания загрузки микропрограммного обеспечения OBU не будет применять новое программное обеспечение немедленно, оно будет применять его при следующем начале работы, поэтому сервер должен будет отправить команду 0х88 после того, как первая таблица состояний будет сформирована OBU, чтобы проверить, было ли применено новое программное обеспечение.

Согласно другому, не показанному, варианту выполнения дополнительный заданный протокол передачи сообщений может быть сформирован следующим образом:

в обычном режиме работы OBU (при полученной обсервации GNSS и установленном соединении GPRS) возможно, что OBU потеряет обсервацию GNSS, но при этом по-прежнему будет иметь доступное соединение GPRS. В таком случае возможны 2 сценария:

1) Если таблица состояний выполнена с возможностью отправки только данных позиционирования, OBU прекратит передачу таблиц состояний до тех пор, пока оно не будет вновь способно получить обсервацию GNSS или его таблица состояний будет переконфигурирована для отправки некоторой дополнительной информации.

2) Если таблица состояний имеет дополнительные данные, выполненные с возможностью отправки помимо данных позиционирования, OBU будет продолжать передавать таблицу состояний, но данные позиционирования будут замещены значением по умолчанию, которое распознается сервером как недействительное.

Согласно другому, не показанному, варианту выполнения настоящего изобретения дополнительный заданный протокол передачи сообщений может быть сформирован следующим образом:

для загрузки микропрограммного обеспечения, если загрузка микропрограммного обеспечения происходит в данный момент, таблица состояний может быть принята сервером в любое время без какой-либо помехи текущему процессу загрузки. Кроме того, любая другая команда (команды) разрешена (разрешены) между передачами 2 блоков, однако сервер не должен отправлять другую команду на загрузку микропрограммного обеспечения до тех пор, пока не поступит ACK.

Согласно другому, не показанному, варианту выполнения дополнительный заданный протокол передачи сообщений может быть сформирован следующим образом:

для загрузки микропрограммного обеспечения, если сообщение конца блока (End Block) потеряно, OBU не будет знать о том, может ли оно использовать загруженное микропрограммное обеспечение. И если ACK не принято сервером, он не может знать, будет ли использоваться новый код. По этой причине должна быть завершена процедура End/ACK.

Согласно другому, не показанному, варианту выполнения дополнительный заданный протокол передачи сообщений может быть сформирован следующим образом:

с точки зрения сервера потеря ответного пакета имеет тот же эффект, что и потеря запроса. Поэтому мы покажем только сообщение потери ответа. Также дублирование запроса с точки зрения OBU имеет тот же эффект, что и прием двух отдельных запросов. По этой причине особо важные запросы, которые не могут быть выполнены более одного раза, должны иметь некоторый механизм для отметки их уникальности (например, обратное считывание состояния при измененной конфигурации).

На Фиг. 8 показана принципиальная блок-схема общего формата усовершенствованной таблицы состояний согласно примерному варианту выполнения настоящего изобретения. Последовательность из идентификатора поля, длины поля и данных поля повторяют до предела заполнения буфера или до конца полей.

Таблица состояний представляет собой структуру из полей (байтов), которая несет информацию на сервер.

Старший бит первого байта указывает на то, имеется ли второй байт. Старший бит отбрасывается и не должен использоваться как часть идентификатора поля.

Данные (возможно кроме таблицы состояний по умолчанию) будут сообщаться в том виде, в котором они представлены в памяти OBU.

Следует отметить, что понятие «содержащий» не исключает множества. Также следует отметить, что признаки, описанные в отношении одного из вышеприведенных примерных вариантов выполнения, могут также быть использованы в сочетании с другими признаками других примерных вариантов выполнения, описанных выше.

Кроме того, при том, что по меньшей мере один примерный вариант выполнения был представлен в вышеприведенном раскрытии и подробном описании, следует понимать, что существует огромное количество вариантов.

Также следует понимать, что примерный вариант выполнения или примерные варианты выполнения представляют собой лишь примеры и не предназначены для ограничения объема, применимости или конфигурации каким-либо образом.

Напротив, вышеприведенное раскрытие и подробное описание обеспечат специалистов в данной области техники удобной принципиальной схемой для реализации примерного варианта выполнения, при этом следует понимать, что в функции и конфигурацию элементов, описанных в примерном варианте выполнения, могут быть внесены различные изменения без выхода за рамки объема, определяемого приложенной формулой изобретения и ее юридическими эквивалентами.