Egts протокол что это

Базовое описание работы с протоколом ЕГТС

В пердыдущей статье я обещал рассказать про протокол EGTS. Это один из множества протоколов, который применятся передачи телеметрических данных. Особенность его в том, что он законодательно закреплен на территории Российской Федерации.

Для описания протокола используется в основом 2 докумета:

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

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

Краткое описание взаимодействия

Указанный протокол является протоколом траспортного уровня. Общая длина пакета протокола транспортного уровняне превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP.

В протоколе предусморено 3 типа пакетов:

Взаимодействие абонентского терминала (АТ) с сервевером происходит следующим образом:

Схематично процесс изображен на рисунке ниже:

Описание структуры пакета

Каждый пакет состоит из 3-х частей:

Схематично это выглядит следующим образом (рис. 1):

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

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

Данное поле является набором стуруктур вида:

Как видно тут структура простая название типа записи, длина секции данных и cами данные. По сути структура похожа на TLV формат в карте тахографа.

Типы подзаписей могут взависимости от типа пакета могут быть следующие:

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

Пример разбора пакета

Для примера разберем один пакет типа EGTS_PT_APPDATA, а затем соберем пакет EGTS_PT_RESPONSE в ответ на этот пакет.

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

В данном примере можно увидеть увидеть что это пакет авторизации c PID=134 пришел от клиента с идентификатором 2 (Object Identifier). Соответственно при его получении клиент ждет соответствующий пакет подтвеждения операции.

Даный пакет будет выглядеть так:

Если разобрать его получим следующую информацию:

По составу он очень похож на предыдущий, но у нас появляется поле Responded Packet ID в котором указывается PID пришедшего пакета, а в секции Subrecord Data отправляем подтвеждение о том что корректо обработали запись с запросом на авторизацию с ( Record Number из пакета авторизации).

Примечания по идентификатору пакета

Как правило инденификатор пакета передается в заголовке пакета в поле nph_request_id, но в некоторых случаях идентификатор пакета передается через счетчик в подзаписи EGTS_SR_ABS_CNTR_DATA в поле CNV. В CN=110 передаются три младших байта. В CN=111 передается один старший байт. Если старший байт отсутсвует, то CN=111 не передается.

Заключение

Надо отметить, что схема подтверждения пакетов может быть разная на разных устройствах, где-то подтвеждается каждая запись (Record Number), а где-то пакет целиком (Responded Packet ID).

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

Для работы с данным протоколом мной было реализовано небольшое приложение GitHub, которое извлекает необходимую информацию и пакета ЕГТС, а также осуществляет базовую авторизацию с устройством. Также есть возможность подключить разные хранилища для выходных данных (из готовых RabbitMQ, PostgreSQL) а также создавать плагины для работы с хранилищем.

Источник

Настройка передачи данных c устройств

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

Через мобильное приложение Яндекс.Курьер

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

Включение доступа у курьеров:

Чтобы предоставить доступ курьерам к приложению Яндекс.Курьер, необходимо:

Инструкция и видеокурс по мобильному приложению доступны по ссылке в разделе Приложение Яндекс.Курьер.

С GPS-устройств

Передача фактических данных с GPS-устройств осуществляется с помощью протокола ERA GLONASS Telematics Standard, приказ МинТранс №285 (EGTS). Данные с устройств должны передаваться в онлайн-режиме.

Требования к конфигурации устройства:

Для идентификации устройства используется так называемый «идентификатор терминала» — число, заданное владельцем устройства, которое передается в служебных данных протокола EGTS. Идентификатор устройства и IMEI-номер GPRS модуля это разные числа. IMEI-номер состоит из 15 до 17 цифр в десятичном представлении. В API можно использовать только числовые идентификаторы и IMEI-номера.

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

Источник

Egts протокол что это

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

Глобальная навигационная спутниковая система

СИСТЕМА ЭКСТРЕННОГО РЕАГИРОВАНИЯ ПРИ АВАРИЯХ

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

Global navigation satellite system. Accident emergency response system. Protocols of data transmission from in-vehicle emergency call system/device to emergency response system infrastructure*

Дата введения 2012-09-01

Сведения о стандарте

1 РАЗРАБОТАН Открытым акционерным обществом «Навигационно-информационные системы» (ОАО «НИС») и Некоммерческим партнерством «Содействие развитию и использованию навигационных технологий».

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 363 «Радионавигация»

4 В настоящем стандарте учтены основные нормативные положения следующих международных документов*:

— Технические требования (TS) Европейского института стандартов электросвязи (European Telecommunications Standards Institute, ETSI) и партнерской Ассоциации групп телекоммуникационных компаний (3rd Generation Partnership Project (3GPP) к системе и протоколам передачи данных применительно к общеевропейской системе eCall;

— Технические требования (TS) Европейского института стандартов электросвязи (European Telecommunications Standards Institute, ETSI) к цифровым телекоммуникационным сетям в части сервиса отправки и приема коротких сообщений

ВНЕСЕНО Изменение N 1, утвержденное и введенное в действие Приказом Росстандарта от 22.04.2014 N 397-ст c 01.09.2014

Изменение N 1 внесено изготовителем базы данных по тексту ИУС N 9, 2014 год

Настоящий стандарт входит в комплекс стандартов «Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях» и является одним из базовых стандартов комплекса.

Система экстренного реагирования при авариях «ЭРА-ГЛОНАСС» предназначена для снижения тяжести последствий дорожно-транспортных происшествий и иных чрезвычайных ситуаций на дорогах Российской Федерации посредством уменьшения времени реагирования экстренных оперативных служб.

Настоящий стандарт описывает протокол обмена данными между автомобильной системой/устройством вызова экстренных оперативных служб и инфраструктурой оператора системы «ЭРА-ГЛОНАСС» и связанный с ним протокол поддержки услуг, включая базовую услугу экстренного реагирования при авариях.

Настоящий стандарт предоставляет все необходимые данные о формате и правилах передачи сообщений и должен использоваться для разработки подсистем передачи данных на стороне автомобильной системы/устройства вызова экстренных оперативных служб и оператора системы «ЭРА-ГЛОНАСС».

Основные положения настоящего стандарта взаимоувязаны с основополагающими национальными стандартами комплекса стандартов «Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях»:

ГОСТ Р 54620-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Автомобильная система/устройство вызова экстренных оперативных служб. Общие технические требования

ГОСТ Р 54721-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Общий порядок оказания системой базовой услуги

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

Настоящий стандарт предназначен для использования:

— производителями автомобильных систем/устройств экстренного реагирования при авариях (терминалов «ЭРА-ГЛОНАСС»);

— оператором системы «ЭРА-ГЛОНАСС»;

— разработчиками и поставщиками услуг на основе навигационно-информационной платформы системы «ЭРА-ГЛОНАСС».

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

Настоящий стандарт устанавливает требования к протоколам обмена данными между автомобильной системой/устройством вызова экстренных оперативных служб и инфраструктурой системы «ЭРА-ГЛОНАСС», включая требования к протоколу обмена данными, связанными с предоставлением системой «ЭРА-ГЛОНАСС» базовой услуги по ГОСТ Р 54721 в целях выполнения требований технического регламента [6] и ГОСТ Р 54620.

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

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

ГОСТ Р ИСО/МЭК 7498-1-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

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

ГОСТ Р 54620-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Автомобильная система/устройство вызова экстренных оперативных служб. Общие технические требования

ГОСТ Р 54721-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Общий порядок оказания системой базовой услуги

ГОСТ 7.75-97 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков

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

3.1 В настоящем стандарте применены термины по ГОСТ Р 52928, ГОСТ Р ИСО/МЭК 7498-1, ГОСТ Р 54620, а также следующие термины с соответствующими определениями:

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

1 Автомобильная система вызова экстренных оперативных служб предназначена для оснащения транспортных средств категории М1, входящих в область применения Правил ЕЭК ООН [7], [8], и N1, входящих в область применения Правил ЕЭК ООН [8].

2 Автомобильное устройство вызова экстренных оперативных служб предназначено для оснащения транспортных средств категории М1, не входящих в область применения Правил ЕЭК ООН [7], [8], и N1, не входящих в область применения Правил ЕЭК ООН [8], а также транспортных средств категорий М2, М3, N2 и N3.

3 Сроки оснащения транспортных средств системами/устройствами вызова экстренных оперативных служб устанавливаются в [6].

4 Автомобильная система вызова экстренных оперативных служб позволяет осуществлять передачу сообщения о транспортном средстве при дорожно-транспортном и ином происшествиях также и в ручном режиме.

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

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

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

3.1.4 сервис: Элемент инфраструктуры телематической платформы системы экстренного реагирования при авариях «ЭРА-ГЛОНАСС», обеспечивающий функциональное выполнение алгоритма той или иной услуги, оказываемой системой, с использованием протокола уровня поддержки услуг.

3.1.5 система экстренного реагирования при авариях; система «ЭРА-ГЛОНАСС»: Федеральная государственная территориально распределенная автоматизированная информационная система, обеспечивающая оперативное получение с использованием сигналов глобальной навигационной спутниковой системы ГЛОНАСС совместно с другой действующей ГНСС информации о дорожно-транспортных происшествиях и при иных чрезвычайных ситуациях на автомобильных дорогах Российской Федерации, обработку, хранение и передачу этой информации экстренным оперативным службам, а также доступ к указанной информации заинтересованных государственных органов, органов местного самоуправления, должностных лиц, юридических и физических лиц.

3.1.6 услуга системы «ЭРА-ГЛОНАСС» базовая: Результат функционирования системы «ЭРА-ГЛОНАСС», состоящий в формировании и передаче экстренных сообщений о дорожно-транспортных происшествиях, приеме, обработке и доведении указанных сообщений в единую дежурно-диспетчерскую службу системы-112 и обеспечении установления (коммутации) двухсторонней голосовой связи с лицами, находящимися в транспортном средстве.

3.1.7 система-112: Система обеспечения вызова экстренных оперативных служб по единому номеру «112».

3.1.8 единый номер «112»: Единый номер вызова экстренных оперативных служб, установленный в российской системе и плане нумерации.

3.1.9 оператор системы экстренного реагирования при авариях «ЭРА-ГЛОНАСС» (оператор системы): Юридическое лицо, осуществляющее деятельность по эксплуатации системы «ЭРА-ГЛОНАСС», в том числе по обработке информации, содержащейся в ее базе данных.

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

— оперативное запоминающее устройство;

Источник

ERA-GLONASS: EGTS protocol spec v.1.6

Чтобы отправить ответ, вы должны войти или зарегистрироваться

25/04/2012 23:16:11 ERA-GLONASS: EGTS protocol spec v.1.6

Тема: ERA-GLONASS: EGTS protocol spec v.1.6

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

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

— обновленные спецификации протокола (EGTS 1.6.rar);
— пример исходного кода на языке программирования С, позволяющий создавать и декодировать пакеты данных; комплект для проверки корректности работы примера исходного кода (edts-1.1.2.2 Source Code 19.03.12.rar)
— исполняемые приложения MS Windows 7, предназначенные для проверки корректности заполнения пакетов данных (EGTS_Validator_v.1.1.3.1.rar).

Данные материалы могут использоваться без каких-либо ограничений при разработке автомобильных систем “ЭРА-ГЛОНАСС”. ОАО “НИС” оформляет права на представленные программы для ЭВМ.

остальную информацию не могу написать либо дать ссылки т.к.

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

Источник

Зоопарк коммуникационных протоколов для GPS-трекеров (часть 2)

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

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

Порядок байтов (endianness)

Порядок от старшего к младшему (big-endian) является стандартным для протоколов TCP и UDP, он используется в заголовках пакетов данных и во многих протоколах более высокого уровня. Поэтому порядок байтов от старшего к младшему часто называют сетевым порядком байтов (network byte order), и он является де-факто стандартом для кодирования бинарных данных в сетевых протоколах.

Проблема в том, что центральные процессоры чаще всего используют порядок от младшего к старшему (little-endian), и поэтому многие производители GPS-трекеров решили кодировать данных в том же формате, что данные хранятся в памяти (т.е. little-endian). Список таких производителей достаточно большой, поэтому приведу только несколько примеров: Baltic Car Equipment (BCE, Литовская компания), Cellocator (крупная международная компания с главным офисом в Израиле) и ГалилеоСкай (известный российский производитель GPS-трекеров со штаб-квартирой в Перми).

Некоторые производители идут еще дальше и кодируют часть данных с одним порядком байт, а часть — с другим. Например, устройства китайской компании Topflytech и польского производителя Tytan GPS отсылают все данные в стандартном сетевом порядке байт, кроме чисел с плавающей запятой, которые отправляются в little-endian формате. Справедливости ради следует отметить, что Tytan GPS исправили проблему во второй версии своего протокола.

Географические координаты

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

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

Знак координаты может храниться отдельно от значения координаты. Например, в протоколе от компании Tzone Digital Technology, биты знаков широты и долготы совмещены со значение направления в 2 байтах данных:

Еще один интересный вариант кодирования координат в бинарных — это двоично-десятичный код (binary-coded decimal или просто BCD). Суть кодирования заключается в том, что каждый десятичный разряд числа записывается в виде его четырёхбитного двоичного кода. Например, широта местоположения Пентагона в протоколах китайских компаний KHD или Gator будет выглядеть следующим образом:

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

Дата и время

Подавляющее большинство или даже все протоколы при передаче координат на сервер содержат одну или несколько временных меток. Обычно это время определения координат GPS приемником, но иногда может быть дата и время внутренних часов GPS трекера на момент, когда посылка была сформирована. Некоторые трекеры отправляют две или даже больше временных меток.

В текстовых протоколах практически всегда время и дата разбиты на отдельные компоненты. Вот несколько примеров представления времени последнего перевода часов в России (26 октября 2014, 2 часа ночи):

Важный момент, который стоит отметить — обычно время передается по гринвичу (UTC или GMT временные зоны). Важно это потому, что сервер и трекер могут находиться в разных временных зонах. Некоторые GPS-трекеры позволяют конфигурировать временную зону. При этом часть из них сообщает выбранную временную зону на сервер, а часть — нет. Для тех, которые не сообщают, требуется вручную задавать зону на сервере.

Один интересный пример проблемы с временными зонами — это безымянный протокол, используемый во множестве дешевых трекеров китайского производства. Трекер присылает локальные дату (год, месяц, день) и время (часы, минуты, секунды), а также время с точностью до миллисекунд по Гринвичу. Интересным в данном случае является то, что имея эти данные, можно посчитать дату по Гринвичу для временных зон от GMT-12 до GMT+12. Например, если на входе мы имеем 2016-01-01 01:00:00 (локальное время) и 59:00:00.000 (GMT), то результат на выходе будет 2015-12-31 59:00:00.000 (GMT). К сожалению, этот способ не работает для временных зон с отклонением от гринвича больше 12 часов.

Еще один примечательный вариант представления времени используется в стандартном протоколе TAIP. Время представлено в виде недель, дней и секунд с 6 января 1980 года. Значимость этой даты не совсем понятна, но это стандарт для многих GPS приемников.

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

В бинарных протоколах дата и время либо разбиты на отдельные компоненты так же, как и в текстовых, либо хранятся в виде временной метки UNIX (количество секунд или миллисекунд с полуночи (00:00:00 GMT) 1 января 1970 года).

Заключение

Вся информация, представленная в данной статье, была накоплена по ходу работы над сервером GPS-мониторинга. Проект полностью Open Source, и если кому-нибудь интересно, то исходный код с реализацией всех приведенных протоколов можно найти на GitHub.

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

Источник