1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 02 октября 2022 в 08:51
Снять ограничение

ГОСТ Р 57187-2016

Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления
Действующий стандарт
Проверено:  24.09.2022

Информация

Название Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления
Название английское Intelligent transport systems. Communication protocol for urban passenger transport on-board telematics unit and dispatching control systems
Дата актуализации текста 01.01.2021
Дата актуализации описания 01.01.2021
Дата издания 28.11.2018
Дата введения в действие 01.06.2017
Область и условия применения Настоящий стандарт распространяется на системы диспетчерского управления городским наземным пассажирским транспортом. Настоящий стандарт устанавливает требования к протоколу обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления. Настоящий стандарт предназначен для использования при организации обмена данными между бортовыми телематическими устройствами транспортных средств городского пассажирского транспорта и системой диспетчерского управления. Настоящий стандарт разработан в соответствии с требованиями к средствам навигации, функционирующим с использованием навигационных сигналов системы ГЛОНАСС или ГЛОНАСС/GPS и предназначенным для обязательного оснащения транспортных средств категории M, используемых для коммерческих перевозок пассажиров, и категории N, используемых для перевозки опасных грузов, которые утверждены [1]. Настоящий стандарт уточняет требования к протоколам обмена, устанавливаемым [1] в части регламентации отдельных структурных элементов фреймов протокола обмена, описанных в дополнительных блоках, дополняющих базовую навигационную информацию
Опубликован Официальное издание. М.: Стандартинформ, 2018 год
Утверждён в Росстандарт


ГОСТ Р 57187-2016

     

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



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



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



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

     

ОКС 35.240.60

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

Предисловие

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

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

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

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

5 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.


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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

3.2 Сокращения

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

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

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

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

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

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

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

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

KC - коммуникационный сервер.

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

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

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

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

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

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

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


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

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

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

1 Таймер

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


Таблица 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

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



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

Код

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

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

1

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

2

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

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

11

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

12

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

13

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

14

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

15

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

16

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

17

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

18

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

19

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

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

21

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

22

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

23

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

24

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

25

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

26

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

27

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Поле

Длина

Тип

Описание

<frame_tag>

2

char [2]

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

<frame_len>

4

unsigned int32

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

<reserved>

6

byte [3]

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

<frame_body>

var

struct

Тело фрейма

<checksum>

1

byte

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

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

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


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

Поле

Длина

Тип

Описание

<pack_len>

4

unsigned int32

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

<pack_num>

4

unsigned int32

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

<pack_type>

2

unsigned int16

Тип пакета

<reserved>

2

byte [2]

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

<pack_body>

var

struct

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

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

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

53 закупки
Показано 1-30 из 53
Назад 1 2 Вперед
Свободные
Р
Заблокированные
Р
Роль в компании Пользователь

Для продолжения необходимо войти в систему

После входа Вам также будет доступно:
  • Автоматическая проверка недействующих стандартов в закупке
  • Создание шаблона поиска
  • Добавление закупок в Избранное