База ГОСТовallgosts.ru » 35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ » 35.240. Применение информационных технологий

ГОСТ Р 57187-2016 Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления

Обозначение: ГОСТ Р 57187-2016
Наименование: Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления
Статус: Действует
Дата введения: 06/01/2017
Дата отмены: -
Заменен на: -
Код ОКС: 35.240.60
Скачать PDF: ГОСТ Р 57187-2016 Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления.pdf
Скачать Word:ГОСТ Р 57187-2016 Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления.doc

Текст ГОСТ Р 57187-2016 Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

57187—

2016

Интеллектуальные транспортные системы

ПРОТОКОЛ ОБМЕНА ДАННЫМИ БОРТОВОГО ТЕЛЕМАТИЧЕСКОГО УСТРОЙСТВА ТРАНСПОРТНОГО СРЕДСТВА ГОРОДСКОГО ПАССАЖИРСКОГО ТРАНСПОРТА С СИСТЕМОЙ ДИСПЕТЧЕРСКОГО УПРАВЛЕНИЯ

Издание официальное

Стшдфпшфцм

201*

ГОСТ Р 57187—2016

Предисловие

1    РАЗРАБОТАН Федеральным государственным бюджетным образовательным учреждением высшего образования «Московский автомобильно-дорожный государственный технический университет» (МАДИ)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 057 «Интеллектуальные транспортные системы»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 24 октября 2016 г. № 1495-ст

4    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты». а текст изменений и поправок — е ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()

© Стандартинформ. 2016

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

II

ГОСТ Р 57187—2016

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................1

3    Термины, определения и сокращения...................................................2

4    Требования к программному обеспечению и алгоритмам работы бортового телематического устройства транспортного средства городского пассажирского транспорта при работе

в составе автоматизированной системы диспетчерского управления...........................2

5    Требования к организации информационного взаимодействия бортового телематического

устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления по протоколу обмена данными...................................6

6    Требования к передаче управляющих команд на бортовое телематическое устройство

транспортного средства городского пассажирского транспорта................................7

7    Требования к бортовому навигационно-связному оборудованию пассажирских транспортных

средств..............................................................................9

Приложение А (обязательное) Пример описания структуры тела информационного пакета.......10

Библиография.......................................................................21

ГОСТ Р 57187—2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Интеллектуальные транспортные системы

ПРОТОКОЛ ОБМЕНА ДАННЫМИ БОРТОВОГО ТЕЛЕМАТИЧЕСКОГО УСТРОЙСТВА ТРАНСПОРТНОГО СРЕДСТВА ГОРОДСКОГО ПАССАЖИРСКОГО ТРАНСПОРТА С СИСТЕМОЙ ДИСПЕТЧЕРСКОГО УПРАВЛЕНИЯ

Intelligent transport systems. Communication protocol for urban passenger transport on-board telematics unit

and dispatching control systems

Дата введения — 2017—06—01

1    Область применения

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

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

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

Настоящий стандарт разработан в соответствии с требованиями к средствам навигации, функционирующим с использованием навигационных сигналов системы ГЛОНАСС или ГЛОНАСС/GPS и предназначенным для обязательного оснащения транспортных средств категории М. используемых для коммерческих перевозок пассажиров, и категории N. используемых для перевозки опасных грузов, которые утверждены [1].

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

2    Нормативные ссылки

8 настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 52928 Система спутниковая навигационная глобальная. Термины и определения.

ГОСТ Р 54024 Глобальная навигационная спутниковая система. Системы диспетчерского управления городским наземным пассажирским транспортом. Назначение, состав и характеристики бортового навигационно-связного оборудования.

ГОСТ Р 54026 Глобальная навигационная спутниковая система. Системы диспетчерского управления городским наземным пассажирским транспортом. Назначение, состав и характеристики решаемых задач подсистемы информирования пассажиров.

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «На-

Издание официальное

1

ГОСТ Р 57187—2016

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

3    Термины, определения и сокращения

3.1    Термины и определения

8 настоящем стандарте применены термины по ГОСТ Р 54024, ГОСТ Р 54026. ГОСТ Р 52928. а также следующие термины с соответствующими определениями:

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

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

3.1.3    тангента: Микрофон-манипулятор с кнопкой управления режимом голосовой связи.

3.1.4    фрейм: Информационная посыпка — контейнер для передачи информационных пакетов при обмене данными между бортовым телематическим устройством транспортного средства городского пассажирского транспорта и коммуникационным сервером.

3.2 Сокращения

В настоящем стандарте применены следующие обозначения и сокращения:

АСДУ — автоматизированная система диспетчерского управления городским пассажирским транспортом;

БТУ — бортовое телематическое устройство транспортного средства городского пассажирского транспорта:

ГЛОНАСС — Глобальная навигационная спутниковая система (Россия);

GPRS — пакетная передача данных по радиоканалам общего пользования;

GPS — Глобальная навигационная система США:

TCP — протокол транспортного уровня передачи данных по сети Интернет;

GSM — цифровой стандарт мобильной связи по радиоканалу;

КС — коммуникационный сервер.

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

системы диспетчерского управления

4.1 БТУ должны содержать программы управления, обеспечивающие отработку команд установленного протокола обмена данными и надежную работу во всех режимах эксплуатации АСДУ при использовании сотовой связи стандарта GSM/GPRS. БТУ должны быть адаптированы к применяемым в АСДУ протоколам и дисциплинам обмена данными, а также согласованы с базовыми техническими и технологическими решениями.

Функционирование БТУ е составе автоматизированных диспетчерских систем реализуется по двум основным вариантам:

2

ГОСТ Р 57187—2016

а)    обмену данными непосредственно между БТУ и коммуникационным сервером АСДУ по сота* соеанному эфирному протоколу;

б)    обмену данными по унифицированному протоколу путем написания производителем БТУ про* граммной службы (драйвера), которая встраивается в коммуникационный сервер АСДУ и обеспечивает обмен данными с БТУ данного производителя.

4.2    Основным режимом для передачи телематической информации от БТУ на коммуникационный сервер АСДУ является режим GPRS.

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

Таблица 1 — Описание событий при сборе и передаче навигационных данных

Наименование события

Описание события

1 Таймер

Данное событие наступает с заданной (настраиваемой) периодичностью. Значение по умолчанию — 30 секунд. БТУ необходимо в обязательном порядке поддерживать данньы вид события

2 Вызов на связь со стороны водителя

Если на БТУ предусмотрена отдельная кнопка вызова

3 Сигнал SOS со стороны водителя

Если на БТУ предусмотрена отдельная кнопка SOS

4 Срабатывание дискретных датчиков

Настройками устанавливается: какие датчики и в каком случае должны генерировать данное событие

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

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

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

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

4.5    БТУ должно обеспечивать получение данных от подключенных внешних контроллеров по каналам передачи RS-232, RS-48S, CAN и привязку этих данных к навигационной информации.

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

4.7    БТУ должно обеспечивать возможность управления дискретными выходами по запросу от коммуникационного сервера.

4.6 БТУ должно обеспечивать возможность интерактивного взаимодействия диспетчера с водителем с помощью дисплея водителя. Дисплей может быть встроен в БТУ или может подключаться к нему через внешний разъем. Базовый размер дисплея водителя — четыре строки по 20 символов на каждой.

БТУ должно обеспечивать;

•    прием и отображение на дисплее неформализованных сообщений от диспетчера;

•    прием и отображение на дисплее формализованных сообщений от диспетчера (см. таблицу 2);

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

(см. таблицу 3);

3

ГОСТ Р 57187—2016

• отправку на коммуникационный сервер подтверждения от водителя факта прочтения сообщения.

Таблица 2 — Пример формирования списка текстов формализованных сообщений для передачи от водителя в диспетчерский центр

Код

Текст сообщения

1 — Экстренный вызов

01

Вызов пожарной службы

02

Вызов полиции

03

Вызов скорой медицинской помощи

04

Вызов ГИБДД

05

Вызов технической помощи

06

Вызов Службы безопасности движения

07

Вызов диспетчера на голосовую связь

2 — Сход с линии

08

Сход: техническая неисправность

09

Сход: неисправность резины

10

Сход: эксплуатационные причины

11

Сход: бригада

12

Сход: дорожно-транспортное происшествие

3 — Сообщения диспетчеру

13

По трассе замечаний нет

14

Гогов к движению

15

Возврат в парк

16

Возврат в парк, буксировка тягачом

17

Работа закончена — ранний сход

18

Нужен обед

19

Нет смены

4 — Задержка движения

20

Скопление постороннего транспорта

21

ДТП постороннего транспортного средства

22

Дорожные работы

23

Погодные условия

5 — Запрос справки

24

Количество выполненных рейсов

25

Время начала и окончания обеда

26

Время пересмены

27

Время окончания работы

28

Текущее расписание движения

4

ГОСТ Р 57187—2016

Таблица 3 — Пример формирования списка текстов формализованных сообщений для отражения на экране индикатора по получению кода сообщения от диспетчерского центра

Код

Содержание сообщения

Команды регулирования движения

1

Отставание от графика движения — войти в расписание

2

Опережение графика движения — войти в расписание

Распоряжения, подтверждения, ответы на запросы водителя

11

Пожарная машина выехала

12

Машина полиции выехала

13

Машина Скорой медицинской помощи выехала

14

Машина ГИБДД выехала

15

Машина технической помощи выехала

16

Машина Службы безопасности движения выехала

17

На остановке прошу вызвать диспетчера на радиосвязь

18

Прием сообщения подтверждаю. Принимаю меры

19

Прием сообщения подтверждаю

Информационные сообщения

21

Скорость снижена на 10 %

22

Скорость снижена на 20 %

23

Осторожно: Гололед

24

Густой туман, схорость 5 кмГч

25

Отмена снижения скорости

26

Рейс за опоздание не бракуется

27

Штормовое предупреждение

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

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

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

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

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

4.9 Инициатором GSM-звонка в АСДУ всегда является диспетчер, водитель должен иметь возможность отправить запрос на связь по каналу GPRS, нажав определенную кнопку на БТУ (либо подключенную к БТУ).

5

ГОСТ Р 57187—2016

При поступлении входящего звонка БТУ необходимо осуществить автоматическое поднятие трубки (прием звонка) и обеспечить голосовую двухстороннюю связь в режиме Hands Free или с использованием микрофона-манипулятора (тангенты).

4.10 БТУ должно обеспечивать возможность настройки базовых параметров посредством SMS сообщений. Минимальный набор настраиваемых параметров: параметры подключения к коммуникационному серверу через GPRS и периодичность сохранения навигационных данных в буфере (периодичность возникновения события Таймер).

5 Требования к организации информационного взаимодействия бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления

по протоколу обмена данными

5.1    Инициатором подключения БТУ к коммуникационному серверу всегда является БТУ. В случае невозможности установления связи с коммуникационным сервером или в случае пропадания связи БТУ предпринимает попытки повторного подключения к коммуникационному серверу с заданной периодичностью. Периодичность попыток подключения — настраиваемая величина.

5.2    Обмен данными между БТУ и коммуникационным сервером осуществляется посредством информационных посылок, называемых фреймами. Фрейм представляет собой контейнер для передачи информационных пакетов. 8 одном фрейме может передаваться как один, так и несколько информационных пакетов. Структура тела каждого информационного пакета описана в таблицах приложения А.

5.3    Каждый переданный информационный пакет (кроме пакетов типов 0. 1. 101) требует подтверждения от принимающей стороны факта успешного получения. Если отправляющая сторона не получила подтверждения в течение заданного промежутка времени (10—15 с), она осуществляет повторную отправку пакета. Если и на этот раз факт доставки пакета не подтвердился, отправляющая сторона разрывает связь с принимающей стороной. Далее БТУ предпринимает попытку восстановить подключение.

5.4    Если от БТУ в течение заданного промежутка времени (1—3 мин) не поступило ни одного пакета. то коммуникационный сервер принудительно разрывает с ним связь. Для предотвращения разрыва связи БТУ может периодически отправлять на коммуникационный сервер информационные пакеты типа 10 (проверка связи). 8 ответ коммуникационный сервер пришлет подтверждающий информационный пакет типа 0.

5.5    Фрейм состоит из следующих составных частей: заголовок фрейма, тело фрейма, контрольная сумма фрейма (см. таблицу 4). Тело фрейма представляет собой контейнер, в котором хранятся информационные пакеты. 8 одном фрейме может передаваться как один, так и несколько информационных пакетов. Контрольная сумма фрейма должна формироваться на основе использования циклического избыточного кода CRC-8.

Таблица 4—Структура фрейма

Попе

Длина

Тип

Описание

<frame_tag>

2

char (2]

Признак начала фрейма. Заполняется символом «-» (тильда)

<frame_len>

4

urvstgned int32

Общая длина фрейма в байтах

<reserved>

6

byte (3]

Зарезервировано. Заполняется нулями

<frame_body>

var

struct

Тело фрейма

<checksum>

1

byte

Контрольная сумма

5.6 Информационный пакет является неделимым элементом обмена информацией между БТУ и коммуникационным сервером. Информационный пакет состоит из следующих составных частей: заголовок информационного пакета, тело информационного пакета (см. таблицу 5). Тело информационного пакета содержит полезную информацию, передаваемую в пакете. Структура и размер этой информации определяются типом пакета.

Пример описания структуры тела информационного пакета приведен в приложении А.

6

ГОСТ Р 57187—2016

Таблица 5 — Структура информационного пакета

Поле

Длина

Тил

Описание

<pack_len>

4

unsigned int32

Общая длина информационного пакета в байтах

<pack_num>

4

unsigned in!32

Уникальный номер пакета. После того как номер достигнет значения 4294967295. он сбрасывается в 0

<pack_type>

2

unsigned int16

Тип пакета

<rese/ved>

2

byte (2]

Зарезервировано. Заполняется нулями

<pack_body>

var

struct

Тело информационного пакета

5.7    Подключившись к коммуникационному серверу. БТУ в первую очередь должно пройти процедуру авторизации. Для этих целей оно отправляет информационный пакет типа 1 и ждет ответа от коммуникационного сервера (10—15 с). В случае отсутствия ответа БТУ повторно отправляет пакет типа 1. Если и на этот раз ответ от коммуникационного сервера не поступил. БТУ разрывает подключение и через определенное время (5 с) повторно предпринимает попытку соединиться с коммуникационным сервером. В ответ на пакет типа 1 коммуникационный сервер отправляет ответный пакет типа 101. информируя об успехе или о неуспехе авторизации. Неуспех авторизации обычно связан с неверно указанным кодом БТУ.

5.8    До тех пор. пока БТУ не авторизуется на коммуникационном сервере, никакие пакеты (за исключением пакета типа 1) коммуникационным сервером не принимаются.

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

5.10    Если в состав БТУ входит бортовой дисплей индикатора водителя, то. в зависимости от его функциональности, водитель имеет возможность отправить формализованное сообщение (выбрать из списка) и неформализованное сообщение (ввести произвольный текст). Передача формализованного сообщения осуществляется посредством информационного пакета типа 3. В ответ коммуникационный сервер формирует информационный пакет типа 0. подтверждая факт успешного получения пакета. Передача неформализованного сообщения осуществляется посредством информационного пакета типа 4. В ответ коммуникационный сервер формирует информационный пакет типа 0. подтверждая факт успешного получения пакета.

5.11    Информация о текущем состоянии дискретных и аналоговых датчиков поступает на коммуникационный сервер в составе дополнительного блока навигационной посылки.

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

5.13    Пример описания структуры тела информационного пакета приведен в приложении А.

6 Требования к передаче управляющих команд на бортовое телематическое устройство транспортного средства городского пассажирского транспорта

6.1 Требования к организации передачи данных по протоколу обмена

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

7

ГОСТ Р 57187—2016

Коммуникационный сервер формирует и передает на БТУ информационный пакет, содержащий управляющую команду (пакеты типа 102 и далее). Каждый такой пакет имеет в своем составе уникальный код сообщения, однозначно определяющий команду, отправленную на конфетное БТУ. В ответ сервер оборудования формирует информационный пакет типа 0. подтверждая факт успешного получения пакета. БТУ информирует коммуникационный сервер об этом отправкой пакета типа 5. Уникальный код сообщения в составе пакета типа 5 должен совпадать с одноименным кодом той управляющей команды, которую он подтверждает. Этот порядок позволяет однозначно определить, на какую команду пришел ответ. В ответ на пакет типа 5 коммуникационный сервер должен отправить на БТУ информационный пакет типа 0. подтверждающий факт успешного получения пакета.

Пример описания структуры тела информационного пакета приведен в приложении А.

6.2 Требования к работе с бортовым дисплеем индикатором (дисплеем водителя)

6.2.1    Если в составе навигационно-связного блока входит бортовой дисплей индикатор водителя, то. в зависимости от его функциональности, диспетчер АСДУ имеет возможность:

а)    отправить водителю формализованное сообщение (выбрать из списка), которое:

1)    не требует реакции со стороны водителя.

2)    требует от водителя подтверждение прочтения;

б)    отправить водителю неформализованное сообщение (ввести произвольный текст), которое:

1)    не требует реакции со стороны водителя.

2)    требует от водителя подтверждение прочтения,

3)    требует от водителя сделать выбор из нескольких вариантов.

Пример описания структуры тела информационного пакета приведен в приложении А.

6.2.2    Отправка формализованного сообщения водителю осуществляется посредством информационного пакета типа 102. Если сообщение требует от водителя подтверждения факта прочтения (поле <msg_type> = 1) и водитель подтверждает его. нажав соответствующую кнопку, то на коммуникационный сервер должен прийти информационный пакет типа 6 и со значением поля <bdi_chotce> = 0. Уникальный код сообщения в составе пакета типа 6 должен совпадать с одноименным кодом той управляющей команды, которую он подтверждает. В ответ на пакет типа 6 коммуникационный сервер должен отправить на БТУ информационный пакет типа 0. подтверждающий факт успешного получения пакета.

6.2.3    Отправка неформализованного сообщения водителю осуществляется посредством информационного пакета типа ЮЗ. Если сообщение требует от водителя подтверждения факта прочтения (поле <msg_type> = 1) и водитель подтверждает его. нажав соответствующую кнопку, то на коммуникационный сервер должен прийти информационный пакет типа 6 и со значением поля <bdi_choice> = 0.

6.2.4    Сообщения, требующие от водителя сделать выбор из нескольких вариантов (поле <msg_ type> = 2). не отличаются от обычных неформализованных сообщений, единственное отличие заключается в том. что строки с вариантами помечены соответствующим битом. Если водитель делает выбор, нажав соответствующую кнопку, то на коммуникационный сервер должен прийти информационный пакет типа 6 и со значением поля <bdi_choice>. равным номеру выбранного варианта. Уникальный код сообщения в составе пакета типа 6 должен совладать с одноименным кодом той управляющей команды, которую он подтверждает. 8 ответ на пакет типа 6. коммуникационный сервер должен отправить на БТУ информационный пакет типа 0, подтверждающий факт успешного получения пакета.

6.2.5    Для запроса фотоснимка с конкретной камеры, коммуникационный сервер формирует информационный пакет типа 104 и передает его на БТУ. Когда БТУ получает снимок с камеры, он формирует и передает на коммуникационный сервер информационный пакет типа 2 (навигационная посылка), к которому прикреплен дополнительный блок типа 4. Если по какой-то причине фотоснимок не может быть получен с камеры, то на коммуникационный сервер поступает информационный пакет типа 2 (навигационная посылка), к которому прикреплен дополнительный блок типа 4. в котором поле <photo> пустое (имеет нулевую длину).

6.2.6    Информация о текущем состоянии дискретных выходов поступает на коммуникационный сервер в составе дополнительного блока навигационной посылки (информационный пакет типа 2). Для изменения состояния конкретного дискретного выхода коммуникационный сервер отправляет на БТУ информационный пакет типа 105.

6.2.7    Коммуникационный сервер может с определенной периодичностью передавать на БТУ дополнительную информацию, относящуюся к радиостанции (например, гаражный номер транспортного средства, на котором установлена данная радиостанция). Для этих целей используется информацион

8

ГОСТ Р 57187—2016

ный пакет типа 106. К каждому широковещательному пакету может быть прикреплен один и более дополнительных блоков навигационной посылки. На каждый широковещательный пакет БТУ необходимо прислать подтверждение.

7 Требования к бортовому навигационно-связному оборудованию пассажирских транспортных средств

Для обеспечения функций взаимодействия основных элементов АСДУ и БТУ. при организации обмена данными между бортовыми телематическими устройствами транспортного средства городского пассажирского транспорта и системой диспетчерского управления, пассажирские транспортные средства должны бьгть оснащены БТУ. работающими по сигналам ГЛОНАСС. ГЛОНАСС/GPS. Состав и характеристики бортового навигационно-связного оборудования по — ГОСТ Р 54024.

9

ГОСТ Р 57187—2016

Приложение А (обязательное)

Пример описания структуры тела информационного пакета

Перечень типов информационных пакетов приведен в таблице А.1.

Таблица А.1 — Перечень типов информационных пакетов

Тип пакета

Описание пакета

Отправитель

0

Подтверждение в лолучеши пакета

БТУ. КС

1

Авторизация на коммуникационном сервере

БТУ

2

Получена навигационная посыпка

БТУ

Э

Получено формализованное сообщение от водителя

БТУ

4

Получено неформализованное сообщение от водителя

БТУ

5

Формализованное (неформализованное) сообщение доставлено

БТУ

6

Получено подтверждение прочтения (выбор опции) от водителя

БТУ

10

Проверка связи

БТУ

11

Служебные команды (зарезервировано)

БТУ

101

Результат авторизации на коммуникационном сервере

КС

102

Отправить формализованное сообщение

КС

103

Отправить неформализованное сообщение

КС

104

Запросить фотоснимок

КС

105

Измеимть состояние дискретного выхода

КС

Структура тела информационного пакета типа 0 приведена в таблице А.2. Таблица А.2

Попе

Длина

Тип

Описание

<conf_lisl>

var

unsigned int32

Коды успешно полученных информационных пакетов

Структура тела информационного пакета типа 1 приведена в таблице А.З. Таблица А.З

Поле

Длина

Тип

Описание

<auth_code>

16

byte

Уникальный ход БТУ

Структура тела информационного пакета типа 2 приведена в таблице А.4. Таблица 4

Поле

Длина

Тип

Описание

<radtonum>

4

unsigned int32

Номер мобильного блока

<radk>type>

2

unsigned inti б

Тип мобильного блока

10

ГОСТ Р 57187—2016

Окончание таблицы 4

Попе

Длина

Тип

Описание

<timenav>

4

unsigned int32

Время навигационной посылки.

Число секуцд, прошедших с 01.01.1970 00:00:00. Мировое время (GMT)

<flags>

1

byte

№17 — достоверность навигационных данных (1 —достоверная. 0 — нет);

№16 — полушарие долготы (1 — Е.О — W ); bits — полушарие широты (1 — N, 0 — S );

№14 — работа от встроенного аккумулятора (1 —да. 0—нет);

№13 — данные пришли из буфера (неоперативные)

(1 —да. 0 — нет);

№12 — состояние SOS (1 — SOS. 0 — нет SOS):

№11 — признак включенного зажигания (1 — вкл.. 0 — выкл.);

№10 — состояние вызова на голосовую связь

(1 — есть запрос на голосовую связь; 0 — нет запроса

на голосовую связь)

<latitude>

4

unsigned int32

Широта в ". умноженная на 10000000

<longitude>

4

unsigned int32

Долгота в *. умноженная на 10000000

<speed>

2

unsigned int16

Скорость движения, км/ч

<course>

2

unsigned int16

Направление движения (вектор скорости), *

<altitude>

2

signed int16

Высота над уровнем моря, м (- 18000 ... + 18000)

<nsat>

1

byte

Число видимых спутников

<lrack>

4

unstgned int32

Накопленный пробег (одометр), м

<flags2>

1

byte

Зарезервировано (всегда 0)

<CSQ>

1

byte

Уровень GSM сигнала (АТ + CSQ)

<dop 1>

var

struct

Дополнительный блок 1

...

<dop n>

var

struct

Дополнительный блок л

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

Таблица А.5 — Структура дополнительного блока навигационной посылки

Поле

Длина

Тип

Описание

<block_len>

4

unsigned int32

Длина дополнительного блока

<btock_type>

1

byte

Тип дополнительного блока

<reserved>

1

byte

Зарезервировано. Заполняется нулями

<bloek_body>

var

struct

Тело дополнительного блока

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

11

ГОСТ Р 57187—2016

Таблица А.6 — Перечень типов дополнительных блоков навигационной посылки

Код

Описание

1

Аналоговые и цифровые датчики

2

Данные аппаратуры подсчета пассажиропотока

3

Данные с дополнительного топливного датчика

4

Фотоснимок

5

Дополнительные датчики

7

Данные or CAN

8

Дополнение к базовой навигационной посылке

11

Именованный параметр

Структуре тела дополни тельного блока типа 1 приведена в таблице А.7.

Таблица А.7 — Аналоговые и цифровые датчики

Попе

Длина

Тип

Описание

<dijn>

2

unsigned int16

Значение 16 цифровых входов (побитно)

<di_out>

2

unsigned inl16

Состояние 16 дискретных выходов (побитно)

<ап_Ы>

2

unsigned int16

Значение аналогового входа 1

<an_m2>

2

unsigned int16

Значение аналогового входа 2

<an_in3>

2

unsigned int16

Значение аналогового входа 3

<an_in4>

2

unsigned int16

Значение аналогового входа 4

<an_in5>

2

unsigned int16

Значение аналогового входа 5

<an_n6>

2

unsigned intte

Значение аналогового входа 6

<an_in7>

2

unsigned int16

Значение аналогового входа 7

<an_m8>

2

unsigned intte

Значение аналогового входа 8

Итого:

20

Структура тала дополнительного блока гипа 2 приведена 8 таблице А.8.

Таблица А.8 — Данные аппаратуры подсчета пассажиропотока

Поле

Длина

Тип

Описание

<irma_door_in1>

1

byte

Пассажиры, вошедшие через первую дверь

<irma_door_in2>

1

byte

Пассажиры, вошедшие через вторую дверь

<irma_door_in3>

1

byte

Пассажиры, вошедшие через третью дверь

<irma_door_in4>

1

byte

Пассажиры, вошедшие через четвертую дверь

<irma_door_out1>

1

byte

Пассажиры, вышедшие через первую дверь

<irma_door_out2>

1

byte

Пассажиры, вышедшие через вторую дверь

<irma_door_out3>

1

byte

Пассажиры, вышедшие через третью дверь

<irma_door_out4>

1

byte

Пассажиры, вышедшие через четвертую дверь

12

ГОСТ Р 57187—2016

Окончание таблицы А.в

Попе

Длина

Тип

Описание

<irma_present_door>

1

byte

Битовая маска присутствия двери <b»t3..bit0): 1 — дверь присутствует

0    — дверь не найдена

Битовая маска закрытия двери <bit7..bit4):

1    —дверь закрывалась

0 — дверь не закрывалась

Итого:

9

Структура тела дополнительного блока типа 3 приведена в таблице А.9. Таблица А.9— Данные от дополнительного топливного датчика

Поле

Длина

Тип

Описание

<fuel_num>

1

byte

Номер топливного бака

<fuel_value>

4

unsigned int32

Значение топливного датчика

<det_status>

1

byte

Состояние топливного датчика

<evel_l>

2

unsigned int16

Уровень топлива в баке {литры)

<lemperature>

1

byte

Температура бака (градусы Цельсия)

«reserved»

4

byte[4)

Зарезервировано. Заполняется нулями

Итого:

13

Структура тела дополнительного блока типа 4 приведена в таблице А.10. Таблица А.10 — Фотоснимок

Поле

Дпииа

Тип

Описание

<photo_num>

1

byte

Номер фотокамеры, от которой пришел снимок

<pboto_res>

1

byte

Разрешение фотокамеры:

0    —QVGA 320x240

1    — VGA 640x480

«reserved»

8

byte{8)

Зарезервировано. Заполняется нулями

«photo»

var

byte[]

Снимок в формате jpeg

Структура тела дополнительного блока типа 5 приведена в таблице А.11. Таблица А.11 —Дополнительные датчики

Пеле

Длина

Тип

Описание

«counter_1»

2

unsigned intIO

Значение счетчпса №1

<соип!ег_2»

2

unsigned intIO

Значение счетчика №2

<соип1ег_3»

2

unsigned intIO

Значение счетчика №3

<соип!ег_4»

2

unsigned intIO

Значение счетчика №4

«temper»

2

signed int16

Датчик температуры (градусы)

«reserved»

22

byte|22]

Зарезервировано. Заполняется нулями

Итого:

32

13

ГОСТ Р 57187—2016

Структура тела дополнительного блока типа 7 приведена 8 таблице А.12.

Таблица А.12 — Данные от CAN

Попе

Дпима

Тип

Описание

«Speed»

1

byte

Скорость автомобиля, км/ч

«FuelConsum»

4

unsigned int32

Расход топлива {0.5 л на бит)

<Fue?Level1>

2

unsigned in(16

Уровень топлива в баке 1 (0.1 % на бит или 0.1 л на бит)

<Fue)Level2>

2

unsigned int16

Уровень топлива в баке 2(0.1 % на бит или 0.1 л на бит)

<Fue1Level3>

2

unsigned int16

Уровень топлива в баке 3(0.1 % на бит или 0,1 л на бит)

«FueiLevel4>

2

unsigned int16

Уровень топлива в баке 4 (0.1 % на бит или 0.1 л на бит)

<Fue*Level5>

2

unsigned int16

Уровень топлива в баке 5(0.1 % на бит или 0,1 л на бит)

«Fue)Level6>

2

unsigned int16

Уровень топлива в баке 6 (0.1 % на бит или 0.1 л на бит)

<RPM>

2

unsigned int16

Обороты двигателя (1 оборот в минуту на бит)

<EngineTime>

4

unsigned in!32

Моточасы (0,01 ч на бит)

«CoolerTemp»

1

signed byte

Температура охлаждающей жидкости (1 °С на бит)

<OilTemp>

4

signed int32

Температура масла в двигателе (0,01 °С на бит)

<FuelTefnp>

1

signed byte

Температура топлива (1 X на бит)

«Mileage»

4

unsigned int32

Общий пробег автомобиля (5 м на бит)

«PressureAxisI»

2

unsigned int16

Давление на ось 1 (0.1 кг на бит)

«PressureAxis2»

2

unsigned int18

Давление на ось 2 (0.1 кг на бит)

<PressureAxis3»

2

unsigned int16

Давление на ось 3 (0.1 кг на бит)

«PressureAxis4»

2

unsigned intl6

Давление на ось 4 (0.1 кг на бит)

<PressureAxis5>

2

unsigned int16

Давление на ось 5 (0.1 кг на бит)

<F!ags>

2

unsigned kit16

bitO — уровень топлива 8 процентах от объема бака, а не в литрах

<reserved>

3

byte[3)

Зарезервировано. Заполняется нулями

Итого:

48

Структура тела дополнительного блока типа 8 приведена 8 таблице А.13.

Таблица А.13 — Дополнение к базовой навигационной посылке

Попе

Длина

Тип

Описание

<S1M>

22

char(22]

Номер SIM-харгы (строка+OxOOh)

<PhoneNum>

14

charf14]

Номер телефона (строка+OxOOh)

«reserved»

16

byte[16]

Зарезервировано. Заполняется нулями

Итого:

56

Структура тела дополнительного блока типа 9 приведена в таблице А.14.

14

ГОСТ Р 57187—2016

Таблица А.14 — Описание транспортного средства

Поле

Длина

Тип

Описание

<TransportTypelD>

4

unsigned int32

Код вида транспорта

<TransporlTypeTitle>

20

char[20]

Наименование вида транспорта (строка+OxOOh)

<TslD >

4

unsigned int32

Код транспортного средства

<GaragNumb>

4

unsigned int32

Гаражный номер транспортного средства

<StateNumb>

15

char[ 15]

Государственный регистрационный знак транспортного средства (строка+OxOOh)

<ModellD>

4

unsigned int32

Код модели (марки) транспортного средства

<ModeTTrUe>

20

char[20]

Наименование модели (марки) транспортного средства (строка+OxOOh)

<DriveflD>

4

unsigned int32

Код водителя

«TabelNumber»

4

unsigned int32

Табельный номер водителя

«ParklD»

4

unsigned int32

Код транспортного предприятия

«Park Title»

20

char[20]

Наименование транспортного предприятия (строка+OxOOh)

«Flags»

2

word

Флаги. Битовая маска.

Ы12 — открепленная машина; bill — специальная машина:

W0 — машина выполняет задание (в наряде)

«reserved»

23

byte(23]

Зарезервировано. Заполняется нулями

Итого

128

Структура тала дополнительного блока типа 10 приведена в таблице А. 15. Таблица А.15 — Дополнительное описание маршрутного транспортного средства

Поле

Длина

Тип

Описание

«Marsh»

0

char[8]

Номер маршрута (строка+OxOOh)

«Graph»

2

unsigned int16

График

«Smena»

1

char| 1]

Смена

«reserved»

21

byte(21]

Зарезервировано. Заполняется нулями

Итого

32

Структура тела дополнительного блока типа 11 приведена в таблице А.16. Таблица А.16 — Именованный параметр

Поле

Длина

Тип

Описание

«ParamNameLen»

1

byte

Длина имени параметра

«ParamName»

var

char(]

Имя параметра. Длина зависит от поля ParamNameLen

«РагатТуре»

1

byte

Код типа параметра. Полный перечень типе» представлен в таблице 18

«ParamValue»

var

bytet]

Значение параметра. Длина зависит от поля РагатТуре

Итого

var

15

ГОСТ Р 57187—2016

Типы именованных параметров приведены в таблице А.17. Таблица А.17

Код

Длина, байт

Описание

0

0

Нет значения

1

1

Целое число без знака

2

1

Целое число со знаком

3

2

Целое число без знака

4

2

Целое число со знаком

5

4

Целое число без знака

6

4

Целое число со знаком

7

8

Целое число без знака

8

8

Целое число со знаком

9

4

Число с плавающей точкой одинарной точности

10

8

Число с плавающей точкой двойной точности

11

1

Логическое значение (равно 0 — false, не равно 0 — true)

12

4

Дага/время. Число секунд, прошедших с 01.01.1970 00:00:00. Мировое время (GMT)

13

1+длина строки

Короткая строка (до 255 символов). Сначала идет 1 байт — длина строки, а затем сама строка

14

2+длина строки

Длинная строка (до 65535 символов). Сначала идут 2 байта — длина строки, а затем сама строка

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

Структура тела информационного пакета типа 3 приведена в таблице А.18.

Таблица А. 18 — Получено формализованное сообщение от водителя

Поле

Длина

Тип

Описание

<radionum>

4

unsigned inl32

Номер мобильного блока

<rad»otype>

2

unsigned int16

Тип мобильного блока

<1imenav>

4

unsigned int32

Навигационное время сообщения. Число секунд, прошедших с 01.01.1970 00:00:00. Мировое время (GMT)

<bdi_code>

2

unsigned intie

Код формализованного сообщения

Итого:

16

Структура тела информационного пакета типа 4 приведена в таблице А.19. Таблица А.19 — Получено неформализованное сообщение от водителя

Поле

Длина

Тил

Описание

<radionum>

4

unsigned int32

Номер мобильного блока

<radiotype>

2

unsigned int16

Тип мобильного блока

<bmenav>

4

unsigned int32

Навигационное время сообщения. Число секунд, прошедших c01.01.1970 00:00:00. Мировое время (GMT)

<b<S_text>

var

char[ ]

Текст неформализованного сообщения

16

ГОСТ Р 57187—2016

Структура тепа информационного пакета типа 5 приведена в таблице А.20.

Таблица А.20 — Формализованное (неформализованное) сообщение или запрос снимка доставлены

Поле

Длина

Тип

Описание

<radionum>

4

unsigned int32

Номер мобильного блока

< radio type>

2

unsigned int16

Тип мобильного блока

<msg_kJ>

4

unsigned int32

Уникальньм код доставленного сообщения

<timenav>

4

unsigned int32

Навигационное время сообщения. Число секунд, прошедших с 01.01.1970 00:00:00. Мировое время (GMT)

Итого:

18

Структура тела информационного пакета типа 6 приведена в таблице А.21. Таблица А.21 — Получено подтверждение прочтения (выбор опции) от водителя

Поле

Длина

Тип

Описание

<radionum>

4

unsigned >nt32

Номер мобильного блока

<radiotype>

2

unsigned int16

Тип мобильного блока

<msg_id>

4

unsigned int32

Уникальный код сообщения, на которое получено подтверждение (выбор опции)

<limenav>

4

unsigned int32

Навигационное время сообщения. Число секунд, прошедших с 01.01.1970 00:00:00. Мировое время (GMT)

<bdi_choice>

1

byte

0 — водитель подтвердил сообщение:

1...20 — водитель выбрал один из предложенных вариантов: 255 — водитель не подтвердил сообщение

Итого:

19

Структура тела информационного пакета типа 10 приведена в таблице А22. Таблица А22 — Проверка связи

Поле

Длина

Тил

Описание

0

Пустое тело

Структура тела информационного пакета типа 11 приведена в таблице А.23. Таблица А23 — Служебная команда

Попе

Длина

Тип

Описание

<radionum>

4

unsigned int32

Номер мобильного блока

<radkrtype>

2

unsigned int16

Тип мобильного блока

<maskjen>

2

unsigned int16

Длина строки с маской службы

<mask_text>

var

char[]

Маска службы

<cmd_len>

2

unsigned int16

Длина строки с командой

<cmd_text>

var

char[)

Команда

Структура тела информационного пакета типа 101 приведена в таблице А.24.

17

ГОСТ Р 57187—2016

Таблица А.24 — Результат авторизации на коммуникационном сервере

Поле

Длина

Тип

Описание

<au1h_res>

1

byte

Результат авторизации:

0    — авторизация выполнена:

1    — ошибка авторизации

Структура тела информационного пакета типа 102 приведена в таблице А.25.

Таблица А.25 — Отравить формализованное сообщение

Попе

Длина

Тип

Описание

<radionum>

4

unsigned int32

Номер мобильного блока

<radiotype>

2

unsigned int16

Тип мобильного блока

<msg_id>

4

unsigned »nt32

Уникальный ход сообщения

<firsl_tirve>

1

byte

Номер строки, с которой начинать вывод

<msg_timeout>

2

unsigned int16

Продолжительность отображения сообщения, с

<sound_flash>

1

byte

Звуковая и световая сигнализации при выводе: Битовая маска звуковой сигнализации (bil3..bit0):

0    — отключена:

1    — минимальная интенсивность;

7 — максимальная интенсивность

Битовая маска световой сигнализации (bit7..bit4):

0    — отключена:

1    — минимальная интенсивность;

7 — максимальная интенсивность

<msg_type>

1

byte

Тип сообщения:

0    — сообщение не требует подтверждения от водителя;

1    — сообщение требует подтверждения от водителя

<msg_0ag>

1

byte

Битовая маска:

ЬК1 — сохранять сообщение в памяти навигационно-связного блока (1 — да. 0 — нет);

bitO — немедленно выводить сообщение на экран (1 — да. 0 — нет)

<bdi_code>

2

unsigned int16

Код формализованного сообщения

<reserved>

4

byte{4|

Зарезервировано. Заполняется нулями

Итого:

22

Структура тела информационного пакета типа 103 приведена в таблице А.26.

18

ГОСТ Р 57187—2016

Таблица А.26 — Отправить неформализованное сообщение

Поле

Длина

Тил

Описание

<radonum>

4

unsigned inl32

Номер мобильного блока

<radiotype>

2

unsigned int16

Тип мобильного блока

cmsgjds-

4

unsigned int32

Уникальный код сообщения

<first_line>

1

byte

Номер строки, с которой начинать вывод

cms^limeoul»

2

unsigned int16

Продолжительность отображения сообщения, с

<sound_ftash>

1

byte

Звуковая и световая сигнализации при выводе: Битовая маска звуковой сигнализации (Ы1Э..ЫЮ):

0    — отключена:

1    — минимальная интенсивность;

7 — максимальная интенсивность

Битовая маска световой сигнализации (toit7..b*t4>:

0    — отключена:

1    — минимальная интенсивность:

7 — максимальная интенсивность

<msg_type>

1

byte

Тип сообщения:

0    — сообщение не требует подтверждения от водителя:

1    — сообщение требует подтверждения от водителя:

2    — от водителя требуется выбор из нескольких вариантов

«msgjlag»

1

byte

Битовая маска:

bill — сохранять сообщение в памяти навигационно-связного блока (1—да. 0 — нет);

bitO — немедленно выводить сообщение на экран (1 — да. 0 — нет)

«reserved»

4

byte[4]

Зарезервировано. Заполняется нулями

<line1>

var

struct

Пакет с текстовой строкой 1

<SneN>

var

struct

Пакет с текстовой строкой N

Структура пакета с текстовой строкой приведена 8 таблице А.27.

Таблица А.27

Поле

Длина

Тил

Описание

<1пе_1еп>

1

byte

Длина пакета со строкой

<line_fiags>

1

byte

Битовое поле:

bitO — строка содержит вариант выбора

«reserved»

3

byte(3]

Зарезервировано. Заполняется нулями

<line_text»

var

char{]

Текст строки

Структура тела информационного пакета типа 104 приведена 8 таблице А.28.

19

ГОСТ Р 57187—2016

Таблица А.28 — Запросить фотоснимок

Попе

Длина

Тип

Описание

«radtonum»

4

unsigned inl32

Номер мобильного блока

«radiotype»

2

unsigned int16

Тип мобильного блока

<photo_num>

1

byte

Номер фотокамеры

<photo_res>

1

byte

Разрешение фотокамеры:

0    —QVGA 320x240

1    — VGA 640x480

<photo_oount>

1

byte

Число снимков

<msg_id>

4

unsigned int32

Уникальный кед сообщения

«reserved»

4

byte[4]

Зарезервировано. Заполняется нулями

Итого:

17

Структура тела информационного пакета типа 105 приведена в таблице А.29.

Таблица А.29 — Изменить состояние дискретного выхода

Поле

Длина

Тил

Описание

<radionum>

4

unsigned inl32

Номер мобильного блока

<radiotype>

2

unsigned int16

Тип мобильного блока

<out_num>

1

byte

Номер дискретного выхода (1..16)

<out_state>

1

byte

Устанавливаемое состояние (0 — выключено. 1 — включено)

<msg_id>

4

unsigned int32

Уникальный код сообщения

«reserved»

4

byte[4]

Зарезервировано. Заполняется нулями

Итого:

16

Структура тела информационного пакета типа 106 приведена в таблице А.30.

Таблица А.30 — Информационный пакет

Поле

Длина

Тип

Описание

<radionum>

4

unsigned int32

Номер мобильного блока

<radiotype>

2

unsigned int16

Тил мобильного блока

<bmenav>

4

unsigned int32

Навигационное время сообщения. Число секунд, прошедших с 01.01.1970 00:00:00. Мировое время (GMT)

«reserved»

6

byte[6]

Зарезервировано. Заполняется нулями

<dop 1»

var

struct

Дополнительный блок 1

...

<dop n»

var

struct

Дополнительный блок п

20

ГОСТ Р 57187—2016

Библиография

(1]    Приказ Министерства транспорта Российской Федерации от 31 июля 2012 г. № 285 «Об утверждении требований к средствам навигации, функционирующим с использованием навигационных сигналов системы ГЛОНАСС или ГТЮНАСС/GPS и предназначенным для обязательного оснащения транспортных средств категории М. используемых для коммерческих перевозок пассажиров, и категории N. используемых для перевозки опасных грузов»

(2]    Ефименко Д.Б.. Кудрявцев А.А. Построение информационных систем на автомобильном транспорте: учеб, пособие М.: МАДИ. 2014. — 104 с.

(3]    Интеллектуальные транспортные системы в автомобильно-дорожном комплексе И В.М. Власов. В.М. Приходько. С.В. Жанказиев. А.М. Иванов. — М.. МАДИ. — М.: ООО «МЭЙЛЕР». 2011. — 487 с.

21

ГОСТ Р 57187—2016

УДК 656.13.072/073:006.354    ОКС 35.240.60

Ключевые слова: бортовое телематическое устройство. ГЛОНАСС, диспетчерское управление. Интел» лектуальная транспортная система, протокол обмена данными, система диспетчерского управления, спутниковая навигация, транспортное средство городского пассажирского транспорта

22

Редактор И.В. Конин Технический редактор В.Н. Прусакова Корректор П.С. Лысенко Компьютерная верстка ЕЛ. Кондрашовой

Сдано а набор 27.10.2016.    Подписано а печать 02.11.2016. Формат 60«84%. Гарнитура Ариал.

Уел. печ. л. 3.26. Уч-иэд. л. 2.95. Тира* 26 экэ. За* 2723.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ». 123995 Москва. Гранатный лер.. 4.