176

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Всем привет! Возникает проблема при ретрансляция данных со Скаута в Wialon. Данные некоторое время (8-12 дней) передаются, а потом прекращаются. Ретранслятор Скаута пишет:

10:21:29 Info 193.193.165.165:20317 - соединение закрыто
10:21:34 Info 193.193.165.165:20317 - Установка соединения...
10:21:35 Info 193.193.165.165:20317 - Успешное соединение.
10:21:35 Info Передача 25 пакетов... ([INPUT: 25000])
10:21:50 Info 193.193.165.165:20317 - Unable to read data from the transport connection: Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера.
10:21:50 Info 193.193.165.165:20317 - соединение закрыто



-------------------
вот сюда, пожалуйста
http://forum.gurtam.com/viewtopic.php?id=3087

Алексей Александров
Скай Телеком
Чебоксары
177

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

lesovick
В ретрансляции с Wialon Hosting имеется небольшой буффер данных. Когда принимающая сторнона недоступна, то в нём канапливаются сообщения для ретранслции, которые потом должны уйти. Буффер конечно ограничен по размеру.

Viacheslav Krival
178

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Alexandrov
По какому протоколу подключаете? Попробуйте через CKAYT RX Extended v2, он реализовать с подтерждениями доставки и ответами.

Viacheslav Krival
179

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Здравствуйте!
Кто знает как ретранслировать приборы Галилео ГЛОНАСС?
Вбиваю то что дала приемная сторона http://91.198.71.237:8010/gate5  протокол soap. Ничего не происходит.
Ретранслятор как то можно самому увидеть отправляет или нет? Есть только  запущен/остановлен, а дальше звони пиши делай что хочешь чтоб узнать!

компания "Magelan" www.magelan-ssm Нижневартовский р-он, Мегион.
Ходак Ю.М.
180

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

yuri20049 пишет:

Вбиваю то что дала приемная сторона http://91.198.71.237:8010/gate5  протокол soap. Ничего не происходит.

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

Аркадий Рушкевич
181

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

yuri20049
ИЗ SOAP протоколов у нас есть два в ретрансляторах на Wialon Hosting - это "EGTS"(это по 285 приказу) и "SOAP"(это по протоколу АСУ ОДС), но как правильно заметил  Obscured - надо анализировать формат пакета, для этого необходима информация от принимающей стороны.

Viacheslav Krival
182

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

krsl пишет:

yuri20049
ИЗ SOAP протоколов у нас есть два в ретрансляторах на Wialon Hosting - это "EGTS"(это по 285 приказу) и "SOAP"(это по протоколу АСУ ОДС), но как правильно заметил  Obscured - надо анализировать формат пакета, для этого необходима информация от принимающей стороны.

3.1 Информация, передаваемая в направлении от внешней системы к платформе, обслуживающей объект

В направлении от Клиента к Серверу осуществляется передача следующих видов информации:

-    SOAP запрос местоположения и состояния объекта. В ответ от Сервера приходит телематическое сообщение

-    Статусное SOAP сообщение о сбое или успешном подтверждении сообщения о местоположении и состоянии объекта, переданного со стороны Сервера. Отправляется Клиентом в ответ на телематическое сообщение, поступившее от Сервера по его собственной инициативе

-    SOAP сообщение с командой для передачи на объект. Сервер в ответ передает статусное сообщение о приеме команды для дальнейшей обработки или ошибку

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

-    Статусное SOAP сообщение о сбое или успешном подтверждении сообщения о  подтверждении выполнения переданной ранее команды, переданного со стороны платформы. Передается Клиентом в ответ на сообщение от Сервера о подтверждении выполнения ранее переданной команды

-    Статусное SOAP сообщение о сбое или успешном подтверждении сообщения о  сообщении, поступившем с объекта, и переданного со стороны Сервера. Отправляется Клиентом в ответ на сообщение от Сервера, содержащее информацию о текстовом или ином сообщении, поступившем с объекта

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

3.2 Информация, передаваемая в направлении от платформы, обслуживающей объект, к внешней системе

В направлении от Сервера к Клиенту осуществляется передача следующих видов информации (последовательность видов информации соответствует последовательности вида информации, приведенной в разделе 3.1. Используйте совместно для лучшего понимания SOAP диалога):

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

-    SOAP сообщение с телематической информацией, передаваемое сервером по его собственной инициативе в момент поступления данных от объекта. Клиент в ответ Серверу возвращает статусное SOAP сообщение о принятии информации или сбое

-    Статусное SOAP сообщение о подтверждении приема команды для передачи на объект или сообщение об ошибке. Передается Сервером в ответ на сообщение от Клиента с командой для объекта

-    Статусное SOAP сообщение о подтверждении приема сообщения для передачи на объект или сообщение об ошибке. Передается Сервером в ответ на сообщение от Клиента с сообщением для объекта

-    SOAP сообщение с подтверждением выполнения команды, ранее переданной на объект. В ответ Клиент передает статусное сообщение о приеме подтверждения о выполнении команды или ошибку

-    SOAP сообщение с сообщением, поступившем с объекта. В ответ Клиент отправляет статусное сообщение о подтверждении приема сообщения или ошибку

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

4 Необходимые сервисы Клиентской и Серверной сторон

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

4.1 Сервисы Серверной стороны

-    Прием запроса на определение местоположения и состояния объекта

-    Прием запроса на отправку команды на объект

-    Прием запроса на отправку сообщения на объект с вариантами ответа

4.2 Сервисы Клиентской стороны

-    Прием местоположения и состояния объекта

-    Прием сообщения от объекта

-    Прием подтверждения о выполнении ранее переданной на объект команды

-    Прием подтверждения о прочтении и варианта ответа на ранее переданное на объект сообщение

5 Формат сообщений сервисов

Ниже подробно описаны форматы соответствующих SOAP запросов и ответов на них от противоположной стороны, как наполненных информацией, так и сообщений о сбое.

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

При необходимости получить внеочередное местоположение и состояние объекта Клиент выдает запрос вида:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:GetCoord>
    <ObjectID>ObjectNumber</ObjectID>
  </ws:GetCoord>
</soapenv:Body>
</soapenv:Envelope>

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

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:GetCoordResponce>
    <ObjectID>ObjectNumber</ObjectID>
    <Coord time="KMLTimeStamp" lon="Longitude" lat="Latitude" alt="Altitude" speed="Speed" dir="Direction" valid="Validity"/>
    <AddInfo motion="Run_mode_on_off" dist="by_distance" online="point_type" mileage="Current_milage"/>
    <DigI inpnum="Input_number"/>
    ...
    <DigO outnum="Output_number"/>
    ...
    <AnalogI num="Input_number" val="Sens_value"/>
    ...
    <PortData port="Port_num" recvd="base64_data_from port"/>
    <Multimedia mmtp="MIME-type_of_data" read="base64_multimedia_data"/>
  </ws:GetCoordResponce>
</soapenv:Body>
</soapenv:Envelope>

В параметре ObjectID передается идентификатор объекта, чье местоположение определяется данным документом (например, номер телефона в формате 79032058458 или другого абонентского оборудования, например, 80066670).

Далее следует обязательная структура Coord, которая определяет географическую составляющую сообщения. Имеются обязательные атрибуты:
- time указывается момент времени UTC (Гринвичское время) определения местоположения. Формат соответствует формату кодирования даты и времени, передаваемого в Гринвиче (YYYY-MM-DDThh:mm:ssZ). Например, 2010-01-29T01:28:01Z соответствует четырем часам двадцати восьми минутам одной секунде московского стандартного времени двадцать девятого января 2010 года.
-    lon, lat – градусы долготы и широты местоположения. Отрицательные значения широты соответствуют южному полушарию. Отрицательные значения долготы соответствуют западному полушарию. Количество знаков в дробной части определяется точностью измерения местоположения, достигаемой бортовым оборудованием, но общее количество значащих цифр целой и дробной частей вместе не должно превышать 15 знаков
-    alt – высота в метрах – опциональный атрибут. Дробное значение
-    speed – скорость в км/ч. Точность один знак после запятой
-    dir – направление движения в градусах от северного направления при вращении по часовой стрелке. Целое число в пределах от 0 до 359
-    valid – признак валидности полученных навигационных данных. Значение 1 соответствует валидным координатам, 0 – не валидным

Разделитель целой и дробной частей – точка.

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

Атрибут motion устанавливается в 1, когда данная координата замерена в режиме, когда объект двигался. Если объект стоял, и не была осуществлена отбивка по дистанции, то устанавливается в 0. Соответственно, в случае отбивки по дистанции или отбивки по таймеру или превышения порога угла поворота, атрибут устанавливается в 1.

Атрибут dist устанавливается в 1, когда посылка сгенерирована после прохождения очередного участка заданной протяженностью (отбивка по пройденной дистанции). Иначе - 0.

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

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

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

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

Далее могут следовать структуры AnalogIn, являющиеся опциональными. Структур может быть несколько, в зависимости от количества одновременно измеряемых на объекте аналоговых величин. Параметр num задает номер аналогового входа, измеренное значение которого посылается вместе с данной координатой. Параметр val задает значение измеренной аналоговой величины. Разделитель дробной и целой частей - точка. Количество знаков в дробной части определяется точностью измерения величины, достигаемой бортовым оборудованием, но общее количество значащих цифр целой и дробной частей вместе не должно превышать 15 знаков

Структура PortData опциональна и содержит в себе два параметра: port - номер порта бортового оборудования, через который подключено дополнительное измерительное оборудование, с которого пришло данное сообщение,  recvd  - является base64 закодированная строка полученного с порта байтового потока.

Структура Multimedia является опциональной и парой параметров задает тип содержимого передаваемой мультимедийной информации - mmtp (в представлении MIME type) и само содержимое, base64 кодированное, - read.

Пример ответа Сервера на запрос местоположения объекта:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:GetCoordResponce>
   <ObjectID>79032058458</ObjectID>
   <Coord time="2010-01-29T01:28:01Z" lon="37.754689" lat="55.6586458" speed="20.1" dir="301" valid="1"/>
  </ws:GetCoordResponce>
</soapenv:Body>
</soapenv:Envelope>

Пример отправки телематического сообщения от полнофункционального AVL оборудования:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
   <ws:GetCoordResponce>
     <ObjectID>80066670</ObjectID>
     <Coord time="2010-01-29T01:28:01Z" lon="37.754689" lat="55.6586458" speed="20.1" dir="301" valid="1"/>
     <AddInfo motion="1" dist="0" online="1" mileage="321.1"/>
     <DigI inpnum="1"/>
     <DigI inpnum="9"/>
     <DigO outnum="1"/>
     <AnalogI num="1" val="0.05"/>
     <AnalogI num="10" val="662.5"/>
     <PortData port="3" recvd="abcd1280"/>
   </ws:GetCoordResponce>
</soapenv:Body>
</soapenv:Envelope>

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

<?xml version='1.0' encoding="windows-1251"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  <env:Body>
   <env:Fault>
     <env:Code>
       <env:Value>env:Receiver</env:Value>
     </env:Code>
     <env:Reason>
      <env:Text xml:lang="en-US">No location info</env:Text>
     </env:Reason>
   </env:Fault>
</env:Body>
</env:Envelope>

5.1.2 Формат сообщений сервиса приема запроса на отправку команды на объект

Если необходимо передать команду на абонентское оборудование, установленное на объекте, то Клиент инициирует передачу следующего XML документа:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:SendCommand>
    <ObjectID>ObjectNumber</ObjectID>
    <CommandID>CommandIdentity</CommandID>
    <CommandString>CommandToSend</CommandString>
  </ws:SendCommand>
</soapenv:Body>
</soapenv:Envelope>

Все параметры обязательны. ObjectNumber задает идентификатор объекта, на который должна быть отправлена команда. CommandID задает уникальный идентификатор команды так, чтобы клиентская сторона позже могла однозначно связать данный идентификатор, используемый, например, в ответе на команду, с исходным идентификатором переданным в данном пакете. Целое число в десятичной системе исчисления от 1 до 2147483647. CommandString задает содержимое передаваемой команды. Зависит от типа абонентского оборудования на объекте.

В ответ на данный запрос Сервер передает статусное ответное сообщение  SendCommandResponce или сообщение об ошибке, как это описано в разделе 5.1.1, указывая Envelope.Body.Fault.Reason.Text соответствующую причину ошибки, которая привела к невозможности принятия команды для отправки на объект.

Формат ответ в случае успешного приёма команды:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:SendCommandResponce>
   <ObjectID>ObjectNumber</ObjectID>
   <CommandID>CommandIdentity</CommandID>
  </ws:SendCommandResponce>
</soapenv:Body>
</soapenv:Envelope>

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

Если необходимо передать текстовое сообщение на абонентское оборудование, установленное на объекте, возможно, с предлагаемыми вариантами ответа, то Клиент инициирует передачу следующего XML документа:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:SendMessage>
    <ObjectID>ObjectNumber</ObjectID>
    <MessageID>MessageIdentity</MessageID>
    <MessageText>MessageToSend</MessageText>
    <Answer num="Answer_number">AnswerString</Answer>
    ...
  </ws:SendMessage>
</soapenv:Body>
</soapenv:Envelope>

Параметры ObjectID, MessageID, MessageText обязательны и задают идентификатор объекта, идентификатор сообщения (см. раздел 5.1.2 в части определения идентификатора команды) и текст сообщения для передачи на объект.

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

В ответ на данный запрос Сервер передает статусное ответное сообщение  SendMessageResponce или сообщение об ошибке, как это описано в разделе 5.1.1, указывая Envelope.Body.Fault.Reason.Text соответствующую причину ошибки, которая привела к невозможности принятия сообщения для отправки на объект.

Формат ответ в случае успешного приёма сообщения:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:SendMessageResponce>
   <ObjectID>ObjectNumber</ObjectID>
   <MessageID>MessageIdentity</MessageID>
  </ws:SendMessageResponce>
</soapenv:Body>
</soapenv:Envelope>

Получение абонентским оборудованием сообщения и отображение его на экране квитируется как обычная команда. Поэтому значение параметра MessageID должно быть уникальным и среди идентификаторов сообщений, и среди идентификаторов команд CommandID (см. раздел 5.1.2). После получения Сервером подтверждения доставки сообщения, сервер инициирует отправку подтверждения выполнения команды, как это описано в разделе 5.2.3.
5.2 Формат сообщений сервисов Клиентской стороны
5.2.1 Формат сообщений сервиса приема местоположение и состояния объекта

Данным сервисом пользуется Сервер, когда по собственной инициативе передает местоположение объекта (например, сразу, как навигационная посылка с бортового оборудования поступила в связной шлюз Сервера). При этом он передает XML документ, практически, совпадающий с документом GetCoordResponce, за исключением самого названия структуры внутри Envelop.Body, которая, в данном случае, носит название PutCoord. Список подчиненных структур, параметров, их обязательность и смысл полностью совпадают с документом GetCoordResponce.

В ответ на данный запрос Клиент передает статусное ответное сообщение  PutCoordResponce или сообщение об ошибке, как это описано в разделе 5.1.1, указывая Envelope.Body.Fault.Reason.Text соответствующую причину ошибки, которая привела к невозможности принятия команды для отправки на объект.

Формат ответ в случае успешного приёма координатной посылки:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutCoordResponce>
   <ObjectID>ObjectNumber</ObjectID>
  </ws:PutCoordResponce>
</soapenv:Body>
</soapenv:Envelope>

Если Клиент подтвердил получение координаты, то Сервер уничтожает ее из своего временного хранилища для данного Клиента.
5.2.2 Формат сообщений сервиса приема сообщений, поступивших от объекта

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

Формат ответ в случае успешного приёма сообщения:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutMessage>
    <ObjectID>ObjectNumber</ObjectID>
    <MessageText>MessageFromObject</MessageText>
    <Time>KMLTimeStamp</Time>
  </ws:PutMessage>
</soapenv:Body>
</soapenv:Envelope>

Параметр ObjectID задает идентификатор объекта, с которого поступило сообщение. Параметр MessageText определяет непосредственно переданный текст. Параметр Time определяет момент времени, когда была инициирована отправка сообщения с бортового оборудования. Подчиняется правилам представления и дешифрации, описанным в разделе 5.1.1. Все параметры являются обязательными.

В ответ на данный запрос Клиент передает статусное ответное сообщение  PutMessageResponce или сообщение об ошибке, как это описано в разделе 5.1.1, указывая Envelope.Body.Fault.Reason.Text соответствующую причину ошибки, которая привела к невозможности принятия команды для отправки на объект.

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutMessageResponce>
   <ObjectID>ObjectNumber</ObjectID>
  </ws:PutMessageResponce>
</soapenv:Body>
</soapenv:Envelope>

Если клиент подтвердил получение сообщения, то Сервер уничтожает его из своего временного хранилища для данного Клиента.
5.2.3 Формат сообщений сервиса приема подтверждений на ранее переданные на объект команды

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

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutComAnswer>
    <ObjectID>ObjectNumber</ObjectID>
    <CommandID>CommandIdentity</CommandID>
    <Time>KMLTimeStamp</Time>
    <AnswerOk>Ok_or_Not</AnswerOk>
    <AnswerString>CommandAnswerString</AnswerString>
  </ws:PutComAnswer>
</soapenv:Body>
</soapenv:Envelope>

Параметр ObjectID задает идентификатор объекта, подтверждение команды с которого поступило на Сервер. Параметр CommandID указывает идентификатор команды, который был указан в момент инициирования команды Клиентом и подтверждение или ошибка на которую поступило с объекта. Параметр Time определяет момент времени, когда была инициирована отправка подтверждения выполнения команды с бортового оборудования. Подчиняется правилам представления и дешифрации, описанным в разделе 5.1.1. Параметр AnswerOk устанавливается в 1, если команда выполнена успешно, 0, если возникла ошибка во время выполнения команды на приборе. Все указанные параметры являются обязательными.

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

В ответ на данный запрос Клиент передает статусное ответное сообщение  PutComAnswerResponce или сообщение об ошибке, как это описано в разделе 5.1.1, указывая Envelope.Body.Fault.Reason.Text соответствующую причину ошибки, которая привела к невозможности принятия команды для отправки на объект.

Формат ответ в случае успешного приёма подтверждения на отправленную ранее команду:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutComAnswerResponce>
   <ObjectID>ObjectNumber</ObjectID>
   <CommandID>CommandIdentity</CommandID>
  </ws:PutComAnswerResponce>
</soapenv:Body>
</soapenv:Envelope>

Если клиент подтвердил получение подтверждения на отправленную ранее команду, то Сервер уничтожает его из своего временного хранилища для данного Клиента.
5.2.4 Формат сообщений сервиса приема подтверждений о прочтении и варианта ответа на ранее переданное на объект сообщение

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

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutMsgAnswer>
    <ObjectID>ObjectNumber</ObjectID>
    <MessageID>MessageIdentity</MessageID>
    <Time>KMLTimeStamp</Time>
    <Answer>AnswerNum</Answer>
  </ws:PutMsgAnswer>
</soapenv:Body>
</soapenv:Envelope>

Параметр ObjectID задает идентификатор объекта, подтверждение прочтения сообщения с которого поступило на Сервер. Параметр MessageID указывает идентификатор сообщения, который был указан в момент инициирования сообщения Клиентом и подтверждение о прочтении на которое поступило с объекта. Параметр Time определяет момент времени, когда бортовым оборудованием был зафиксирован факт прочтения отправленного ранее сообщения или был выбран вариант ответа на сообщение.  Подчиняется правилам представления и дешифрации, описанным в разделе 5.1.1. Все указанные параметры являются обязательными.

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

В ответ на данный запрос Клиент передает статусное ответное сообщение  PutMsgAnswerResponce или сообщение об ошибке, как это описано в разделе 5.1.1, указывая Envelope.Body.Fault.Reason.Text соответствующую причину ошибки, которая привела к невозможности принятия команды для отправки на объект.

Формат ответ в случае успешного приёма подтверждения о прочтении или варианта ответа на отправленное ранее сообщение:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
  <ws:PutMsgAnswerResponce>
   <ObjectID>ObjectNumber</ObjectID>
   <MessageID>MessageIdentity</MessageID>
  </ws:PutMsgAnswerResponce>
</soapenv:Body>
</soapenv:Envelope>

Если клиент подтвердил получение подтверждения о прочтении или варианта ответа на сообщение, то Сервер уничтожает его из своего временного хранилища для данного Клиента.
6 Статус документа

Версия документа 1.1.

Данный документ имеет статус спецификации.

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

компания "Magelan" www.magelan-ssm Нижневартовский р-он, Мегион.
Ходак Ю.М.
183

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

И вводная часть.
1 Вводная информация
Данный документ даёт пояснения по использованию документа «Взаимодействие платформ местоопределения и управления».

Взаимодействующими платформами являются платформа М2М и платформы интегрируемых существующих телематических операторов предоставления телематических услуг.

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

В свою очередь, инфраструктура М2М в терминах протокола Клиентом.
3 Сервисы, обязательные к реализации на стороне Сервера
В рамках предполагаемой интеграции необходимо реализовать сервис запроса на отправку команды на объект (см. разделы 4.1 и 5.1.2 документа протокола).

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

Доставка до БО команды, принятой Сервером от Клиента (см. раздел 5.2.2 протокола), должна быть осуществлена в десятисекундный срок при условии наличия канала связи между БО и связным шлюзом Сервера. Кроме того, при отсутствии на момент поступления команды канала связи между связным шлюзом сервера и БО Сервер ответственен за временное хранение команды. Роме того, связной шлюз Сервера должен предусматривать механизм повторных попыток отправки команды на БО при условии возникновения сбоев при передаче команды. Количество попыток и интервал между ними определяется системой сервера самостоятельно, но число попыток не должно быть менее трёх. Только после всех предпринятых неудачных попыток доставки команды на БО Сервер передаёт Клиенту сообщение об ошибке выполнения переданной ранее команды (см. раздел 5.2.3 протокола).

Временной интервал между событием поступления телематического сообщения от БО на связной шлюз Сервера и моментом её отправки Клиенту может составлять до 1 (одной) минуты. Но стоит учитывать, что при временном контроле выполнения маршрутных заданий задержка поступления и обычных (нетревожных) координатных сообщений может быть критической. Поэтому, по возможности, Сервер должен передавать Клиенту и этот тип информации с минимальными задержками.
5 Уточнения по составу сообщений
Во всех сообщениях значение параметра идентификатора объекта должно представлять из себя строку длиной 6 (шесть) символов, состоящую из арабских цифр. Если в собственной системе Сервера объект имеет более короткий идентификатор, то срока дополняется слева символами нуля. Если в собственной системе Сервера объект имеет более длинный идентификатор, то Клиенту передаётся последние 6 символов.

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

Если БО не поддерживает измерение высотной составляющей координаты, то в поле высоты Сервер должен занести значение 0.0.

На этапе интеграции владелец Сервера передаёт владельцу Клиента список целесообразных к применению, исходя из рассмотрения ТТ, команд, их результирующего формата строки для отправки на Сервер в парамтре CommandString в сообщении, описанном в разделе 5.1.2 протокола, перечня, сути и формата отдельных параметров команды, а так же вариантов строк ошибок, которые могут поступить в ответ на выполнение данной команды в параметре AnswerString в сообщении, описанном в разделе 5.2.3 протокола.

Представление всех текстовых строк осуществляется в наборе символов кодовой страницы Windows-1251.

компания "Magelan" www.magelan-ssm Нижневартовский р-он, Мегион.
Ходак Ю.М.
184

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Это унифицированный протокол НИС (он же "Олимпстрой").

Кстати, Слава, а почему "EGTS" - это SOAP? Это же бинарный протокол для ЭРА-ГЛОНАСС, ну и для 285-го приказа.

Аркадий Рушкевич
185

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Obscured пишет:

Это унифицированный протокол НИС (он же "Олимпстрой").

Кстати, Слава, а почему "EGTS" - это SOAP? Это же бинарный протокол для ЭРА-ГЛОНАСС, ну и для 285-го приказа.

Так почему же не транслирует?

компания "Magelan" www.magelan-ssm Нижневартовский р-он, Мегион.
Ходак Ю.М.
186

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Obscured пишет:

Кстати, Слава, а почему "EGTS" - это SOAP? Это же бинарный протокол для ЭРА-ГЛОНАСС, ну и для 285-го приказа.

Да Аркаш, EGTS бинарник, он не причём. Уже повязли в этих протоколах, сейчас все про 285 приказ спрашивают, вот он и сидит в голове. Ошибся. Всё верно, надо НИС.

yuri20049 пишет:

Так почему же не транслирует?

Значит что-то на приёмной стороне, пускай логи смотрят. Мы по НИСУ много объектов ретранслируем, там точно всё работает корректно.

Viacheslav Krival
187

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

yuri20049

Вот даже пример реального пакета с нашего ретранслятора:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
<ws:PutCoord>
<ObjectID>00240783</ObjectID>
<Coord time="2012-12-25T08:22:16Z" lon="38.851615" lat="58.048155" alt="115" speed="0.2" dir="0" valid="1" />
<AnalogI num="3" val="0.000000" />
</ws:PutCoord>
</soapenv:Body>
</soapenv:Envelope>

Он такой же как в описанной документации:

yuri20049 пишет:

Пример отправки телематического сообщения от полнофункционального AVL оборудования:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
   <ws:GetCoordResponce>
     <ObjectID>80066670</ObjectID>
     <Coord time="2010-01-29T01:28:01Z" lon="37.754689" lat="55.6586458" speed="20.1" dir="301" valid="1"/>
     <AddInfo motion="1" dist="0" online="1" mileage="321.1"/>
     <DigI inpnum="1"/>
     <DigI inpnum="9"/>
     <DigO outnum="1"/>
     <AnalogI num="1" val="0.05"/>
     <AnalogI num="10" val="662.5"/>
     <PortData port="3" recvd="abcd1280"/>
   </ws:GetCoordResponce>
</soapenv:Body>
</soapenv:Envelope>

Viacheslav Krival
188

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

krsl пишет:

yuri20049

Вот даже пример реального пакета с нашего ретранслятора:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
<ws:PutCoord>
<ObjectID>00240783</ObjectID>
<Coord time="2012-12-25T08:22:16Z" lon="38.851615" lat="58.048155" alt="115" speed="0.2" dir="0" valid="1" />
<AnalogI num="3" val="0.000000" />
</ws:PutCoord>
</soapenv:Body>
</soapenv:Envelope>

Он такой же как в описанной документации:

yuri20049 пишет:

Пример отправки телематического сообщения от полнофункционального AVL оборудования:

<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
   <ws:GetCoordResponce>
     <ObjectID>80066670</ObjectID>
     <Coord time="2010-01-29T01:28:01Z" lon="37.754689" lat="55.6586458" speed="20.1" dir="301" valid="1"/>
     <AddInfo motion="1" dist="0" online="1" mileage="321.1"/>
     <DigI inpnum="1"/>
     <DigI inpnum="9"/>
     <DigO outnum="1"/>
     <AnalogI num="1" val="0.05"/>
     <AnalogI num="10" val="662.5"/>
     <PortData port="3" recvd="abcd1280"/>
   </ws:GetCoordResponce>
</soapenv:Body>
</soapenv:Envelope>

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

* Имя:               
Протокол ретрансляции:SOAP               
Сервер:http://91.198.71.237:8010/gate5               
Логин:               
Пароль:
И ничего нет у приним. стороны.

компания "Magelan" www.magelan-ssm Нижневартовский р-он, Мегион.
Ходак Ю.М.
189

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

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

avl_retranslator[nis]: delivered message from unit '861785005217074' to 'http://91.198.71.237:8010/gate4' for time: 2013-01-30 15:06:16

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

avl_retranslator[nis]: could not deliver message from unit '868204001654069' to 'http://91.198.71.237:8050/gate4' due to: Timeout was reached

Отсюда вывод что всё доставляется, а почему не разбирается и не ложится в базу это надо смотреть на их стороне. И я что-то сомневаюсь что не нужна авторизация.

Viacheslav Krival
190

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

krsl пишет:

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

avl_retranslator[nis]: delivered message from unit '861785005217074' to 'http://91.198.71.237:8010/gate4' for time: 2013-01-30 15:06:16

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

avl_retranslator[nis]: could not deliver message from unit '868204001654069' to 'http://91.198.71.237:8050/gate4' due to: Timeout was reached

Отсюда вывод что всё доставляется, а почему не разбирается и не ложится в базу это надо смотреть на их стороне. И я что-то сомневаюсь что не нужна авторизация.

Спасибо! Сейчас попробуем связаться.

компания "Magelan" www.magelan-ssm Нижневартовский р-он, Мегион.
Ходак Ю.М.
191

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Может кто подскажет, какой протокол для АСУ ОДС Москва ставить? SOAP не проходит...

Юрий
www.naviru.ru - полный комплекс услуг. Wialon Hosting
192

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

TopNavi
Я точно не знаю, но скорее всего в АСУ ОДС Москва стоит М2М софт. Так, что попробуйте слать по протоколу cyber_glx или по Nis.

Симаков Алексей Арифович
navi-track.ru, glonass.center
тел.:+7-995-319-34-99
"Скидки есть у всех, а у нас можно торговаться!!!"
193

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

TopNavi пишет:

SOAP не проходит...

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

Viacheslav Krival
194

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

TopNavi пишет:

Может кто подскажет, какой протокол для АСУ ОДС Москва ставить? SOAP не проходит...

для SOAP адрес сервера имеет вид

_http://ip_address:port/ или
_https://ip_address:port/username

Если вы просто укажете IP и порт, ничего работать не будет.

WDC Administrator
Gurtam
195

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

bako пишет:
TopNavi пишет:

Может кто подскажет, какой протокол для АСУ ОДС Москва ставить? SOAP не проходит...

для SOAP адрес сервера имеет вид

_http://ip_address:port/ или
_https://ip_address:port/username

Если вы просто укажете IP и порт, ничего работать не будет.

Все что мне предоставили:
Под данной учетной записью вам доступно:
1.    АРМ (автоматизированное рабочее место) Телеметрический контроль.
Точка доступа: _http://ods.mos.ru/udo-telemetry/index.html
2.     Возможность передавать данные от устройств ГЛОНАСС в АСУ ОДС через веб-сервис:
_http://ods.mos.ru/telemetry/telemetryWebService.
WSDL веб-сервиса _http://ods.mos.ru/telemetry/telemetryWebService?WSDL.

Про порт даже намека нету...

Юрий
www.naviru.ru - полный комплекс услуг. Wialon Hosting
196

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

увидел сегодня новый тип протокола "TransNavi", предполагаю он имеет отношение к ПО Дортранснавигация?, если да, то в каком виде он работает и что из себя представляет?

Компания "Навигационные системы Урала"
www.navsysural.ru
197

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Коллеги, ретранслировал ли кто-нибудь на Воронежское РЦНМУ? Протокол прислали - вылитый Олимпстроевский. Выбрал ретранслятор NIS. Они данные получают, но косячные:

14/05/2013 05:44:20.028 (I) Request:  POST https://94.141.63.53:8443/gate6
<?xml version="1.0" encoding="windows-1251"?>
<soapenv:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
<soapenv:Header/>
<soapenv:Body>
<ws:PutCoord>
<ObjectID>868204002565751</ObjectID><Coord time="2013-05-14T05:40:22Z" lon="39.703028" lat="47.234316" alt="117.000000" speed="0" dir="0" valid="1" motion="0"/>
<AddInfo online="1"/>
<AnalogI num="1" val="0.000000"/>
<AnalogI num="2" val="0.000000"/>
<AnalogI num="3" val="0.000000"/>
<AnalogI num="4" val="0.000000"/>
<AnalogI num="9" val="0.000000"/>
<AnalogI num="10" val="0.000000"/>
<AnalogI num="11" v

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

198

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

Добрый день всем,
при заведении нового ретранслятора, обратил внимание что появились новые типы протоколов, кто знает что за протоколы и где они применяются:
SOAP, TransNavi, NVG, RTTI, VT 300  ?

Компания "Навигационные системы Урала"
www.navsysural.ru
199

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

SOAP - "олимпийский"

200

Ретрансляция данных с Wialon на другие платформы и наоборот

Re: Ретрансляция данных с Wialon на другие платформы и наоборот

NVG - это ЕНДС.
TransNavi - (предположительно) Дортранснавигация.
VT 300 - не знаю.
RTTI появился видимо совсем недавно, информации о нем нигде нет.

Маркелов Сергей
http://psm-group.com
http://psmvideo.ru
Дистрибуция оборудования для мониторинга, видеонаблюдения и СКУД