Универсальный интерфейс для аппаратно-программной платформы мобильных объектов систем мониторинга и управления транспортом

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

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

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

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

– навигационная информация (координаты, время);

– системная (служебная) информация (данные о работоспособности системы);

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

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

– минимизация передаваемой информации;

– интеграция передаваемой информации с навигационными данными.

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

Чем чаще данные будут передаваться в центр сбора данных, тем более подробным будет трек движения, но при этом увеличивается объем данных, которые необходимо передать. Частоту передачи данных можно уменьшить с одного раза в секунду до одного раза в 15 сек. При этом уменьшаются объем передаваемых данных и занятость канала. Однако в данном случае ухудшается качество трека, что может оказать негативное влияние на систему мониторинга: например, в системе мониторинга пассажирского транспорта будет затруднено вычисление времени прохождения автобусом остановочных пунктов. Таким образом, необходимо, с одной стороны, максимально уменьшить частоту передаваемых данных, а с другой – сохранить необходимую информацию.

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

Предлагается ввести следующие параметры управления:

• 1.    Tm – маяк (параметр, задающий минимальную частоту для передачи данных (от 1 с до 24 ч). Интервал между сеансами передачи данных не должен превышать величину данного параметра.

• 2.    Ti – интервал передачи данных (параметр, значение которого указывает, с каким интервалом будут происходить попытки отправки данных, не имеющих первостепенного приоритета). В случае неудачи новая попытка будет предпринята в следующем интервале.

• 3.    S – пройденное расстояние (параметр, обозначающий расстояние, при удалении на которое должны фиксироваться навигационные данные). Для городских условий достаточно 200– 300 м, для загородных трасс – 500–800 м.

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

• 5.    Vmax – превышение скорости (величина скорости, превышение которой должно сопровождаться фиксацией навигационных данных).

• 6.    Kin – вход в контрольную точку или зону (параметр, обозначающий факт вхождения подвижного объекта в заданную область (окружность или многоугольник)). Набор контрольных точек или зон хранится на терминале.

• 7.    Kout – выход из контрольной точки или зоны (параметр, обозначающий факт оставления подвижным объектом заданной области (окружности или многоугольника)). Набор контрольных точек или зон хранится на терминале.

• 8.    Kline – прохождение контрольной линии (параметр, обозначающий факт пересечения подвижным объектом контрольной линии). Набор контрольных линий хранится на терминале.

• 9.    A – срабатывание датчика (группа параметров для датчиков). Данные должны фиксироваться по факту срабатывания какого-либо датчика (аналоговый, цифровой, "сухой контакт") или преодоления этим датчиком контрольного значения.

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

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

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

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

Каждый пакет интерфейса 70h (табл. 1–4) состоит из двух частей заголовка и блоков (блока) данных и имеет следующую структуру:

Заголовок

Блок данных 1

Блок данных 2

Блок данных n

Структура заголовка пакета:

PID

RR

DD

SS

YYY

XXX

Таблица 1

Описание структуры заголовка

Наименование поля	Описание
PID	Признак пакета. Зарезервированное значение 70h
RR	Резервный байт, введен для дальнейшей возможности модификации протокола
DD	Дата и время (точность до 0,1 с)
SS	Служебная информация стартового блока
YYY	Широта на момент старта
XXX	Долгота на момент старта

Описание служебного байта SS

Таблица 2

Бит	Описание	Возможные значения
7	Актуальность данных о координатах в момент текущего измерения (при отсутствии приема навигационной информации)	0 – данные не действительны (поля Dxn и Dyn отсутствуют); 1 – данные действительны
6	Признак длины текущего дельта-блока	0 ^ 3 байт; 1 + 5 байт
5	Текущая широта	0 (N ) – северная; 1 (S) – южная
4	Текущая долгота	0 (E) – восточная; 1 (W) – западная
3	Знак изменения координаты по широте	0 – положительное или нулевое изменение; 1 – отрицательное изменение
2	Знак изменения координаты по долготе	0 – положительное или нулевое изменение; 1 – отрицательное изменение
1	Пользовательский бит	Зависит от конкретной системы
0	Пользовательский бит	Зависит от конкретной системы

Таблица 3

Заголовок блока данных	Зарезервированная часть
Тип смещения времени Байт смещения времени 1 Байт смещения времени 2	0 – малое (25 с); 1 – среднее (110 мин); 2 – длительное (19 дней) Количество секунд, прошедших с предыдущего момента передачи данных (10, если тип смещения равен 0, 1, 2) Количество секунд, прошедших с прошлого момента передачи данных (10, если тип смещения равен 1, 2)
Байт смещения времени 3	Количество секунд, прошедших с прошлого момента передачи данных (10–2)
Смещение координат	Актуальность данных
(SS-блок)	Признак формата текущего дельта-блока Текущая широта Текущая долгота Знак изменения координаты по широте Знак изменения координаты по долготе Пользовательские данные
Дельта-блок 1	–
Дельта-блок 1.1	–
Дельта-блок 2	–
Дельта-блок 2.1	–
Номер шаблона для до-	Присутствует, если в заголовке признак дополнительных данных равен
полнительных данных	единице (число от 0 до 255)
Блок дополнительных данных	Присутствует, если в заголовке 5-й бит равен единице
Блок данных событий	Последовательность данных, подлежащих передаче при возникновении события, сгенерировавшего текущий пакет

Описание структуры блока данных

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

Номер шаблона дополнительных данных

Данные

Пример шаблона с системными данными приведен ниже.

Таблица 4

Структура шаблона 1 с системными данными

Параметр	Описание
Температура	Температура микроконтроллера в диапазоне от -31 до +71 ° С
Напряжение	Напряжение бортовой сети в диапазоне 0 ^ 51 В
сети
Напряжение	Напряжение аккумулятора в диапазоне 0 ^ 51 В
аккумулятора
Количество	Количество видимых навигационных спутников 0 ^ 31
спутников
Тип спутни-	Тип выбранной спутниковой навигационной системы (1 – GPS, 2 – Глонасс, 0 – совме-
ков	щенный)
Уровень сиг-	Уровень качества сигнала GSM в диапазоне 0 ^ 31
нала GSM
Высота	Высота над уровнем моря в диапазоне от -3000 до 13 000 м
Скорость	Скорость подвижного объекта в диапазоне 0 ^ 255 км/ч

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

PID

Service

Time

EventID

DataSize

Data

Таблица 5

Описание структуры интерфейса 71h

Сокращенное наименование	Описание
PID	Имеет значение, равное 71h, и встречается в начале сообщения только один раз; данное поле указывает на то, что в наборе поступивших данных пришел именно описываемый пакет
Service	Поле, содержащее служебную информацию для текущего события и связанных с ним данных, а именно: – 0-й бит: информация о том, имеется ли еще какое-либо событие, следующее в данном пакете за текущим; принимает значения 0 либо 1 –1-й бит: признак, указывающий на то, является ли данное событие квитанцией – биты со 2-го по 6-й: номер квитанции (равен нулю, если данное событие не является квитанцией, либо не предполагает ответа в виде квитанции)
Time	Время наступления события (формат совпадает с используемым в протоколе 70h)
EventID	Код события (согласно таблице событий)
DataSize	Размер данных для текущего события (в байтах)
Data	Непосредственно данные; это поле не подлежит унификации, его структура определяется требуемой для конкретного события информацией

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

PID

Service

Time

EventID

Data

Формат пакета практически идентичен пакету 71h (поле PID имеет значение 72h), отличие лишь в том, что в нем отсутствует поле величины размера данных. Это обусловлено тем, что информация о событиях, пересылаемых данным пакетом, имеет фиксированную длину, определяемую номером того или иного события.

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

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

Сонькин Дмитрий Михайлович – ассист. Института кибернетики

Миньков Александр Сергеевич – асп. Томского политехнического университета; тел. (382-2)51-75-30

Дата поступления – 08.11.11