Сообщения передают события, происходящие в системе, на сервер. Сервер подтверждает получение сообщений. В настоящее время подтверждение по LoRa не реализовано, сообщение считается отправленным, если получен confirm на uplink с данными.

При отсутствии подтверждения события копятся в буфере и попытки отправки повторяются периодически. События из буфера отправляются, начиная со старейшего. Если буфер переполняется, новые события вытесняют старые. События имеют циклический порядковый номер (параметр SEQ uint16_t), что позволяет обнаруживать потерю событий.

Размер буфера зависит от версии программы (и транспорта).

Сообщение может передаваться:

  • CAS360, CAS1/2: через LoRa инфраструктуру
  • CAS360, CAS1/2: по IP-сети (WiFi, LAN) на заданный в конфигурации CoAP-сервер.
  • CAS360: по IP-сети (LTE) на заданные в конфигурации HTTPS-сервер и его контекст. Upload бинарных данных.
    Метод POST, ресурс <в настройках CAS360>, Content-Type: application/cbor
    Сообщение в HTTP body 
    Подтверждение получения – HTTP response 2xx

Отправка через LoRa

На LoRa порт 11

Заголовок пакета такой же, как для сенсоров, далее сообщение (вместо блока сенсоров), см. Описание форматов пакетов

Подтверждение получения – не реализовано, подтверждением считается confirmation пакета с базы LoRa

Отправка через IP

По IP-сети (LTE, WiFi, LAN) на заданный в конфигурации CoAP-сервер.

Метод POST, ресурс /msg

Пример запроса: POST /msg

Content-Format:application/cbor

Сообщение в payload

Подтверждение получения – CoAP Response 2.xx

Структура сообщения

Структура сообщения – последовательность CBOR-элементов (CBOR-stream, rfc7049 section 3.1):

VERSION(int=-1), HEADER, EVENT, EVENT, ...

VERSION иденифицирует дальнейшую структуру, должен быть integer и равен -1. Иначе формат сообщения считать неизвестным.

HEADER идентифицирует отправляющую систему CAS360 и несет общие параметры, EVENT несет информацию об одном событии.

Каждый HEADER и EVENT – CBOR map, то есть, набор полей key:value (key это int).

Могут приходить сообщения без EVENT, это keepalive – используются для проверки связи при отсутствии полезных данных.

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

Идентификаторы полей (key) обычно выбираем в диапазоне -24..23, чтобы занимали 1 байт в CBOR.

Элемент VERSION

Тип integer, значение определяет дальнейшее содержимое. Для нижеописанной структуры значение =-1. Чтобы отличать от сенсоров в случае чего.

Поля HEADER

Множественные Key это альтернативы, придет какой-то один.

NameKeyValue TypeDescription

CASID


SERIAL

1


2

uint32


uint32

Unique (hopefully) identifier of sending CAS360 system, generated automatically (linked to tablet PC hardware) 

Looks like arbitrary number

Serial number  of sending CAS1 reader

UPTIME3uint32optional Device Uptime at pack sending, seconds




Поля EVENT

NameKeyValue TypeDescription

UPTIME

TIME

-4

-3

uint32

uint32

Device Uptime of Event, seconds

Время события, секунды с UNIX epoch, UTC+0

SEQ-2uint16Циклический сквозной порядковый номер события, для обнаружения потерь
KIND-1intРод события: 0-SYS, 1-CAS, ...
EVENT0intСобытие
...

дополнительные поля, специфичные для каждого события EVENT

События SYS (KIND=0)

EVENT

Value

Description

Test-123test event (CLI: msgtest N)
Reset0

Дополнительные поля события Test

Name

Key

Value Type

Description

TESTCNT

-456

uint

Счетчик тестовых событий

События CAS (KIND=1)

EVENT

Value

Description

ZoneRed0Вход в Красную зону
ZoneYellow1Вход в Желтую зону
ZoneGreen2Вход в Зеленую зону
ZoneOut3Выход (пропадание метки из эфира)
ZonePark4Парковка метки (прекращение обнаружения)
ZoneUndef5Зона не определилась

Дополнительные поля событий CAS. Множественные Key это альтернативы, придет какой-то один.

Name

Key

Value Type

Description


EUI

SERIAL

CASID


1

2

3

4


uint64

uint32

uint32

<TBD>

Идентификатор метки. 

EUI64 (для меток не-ULUN)

серийный номер (для меток ULUN, пересчитывать в EUI64)

CAS_ID для систем CAS360 (при сближении с другой системой CAS360)

reserved

Основным идентификатором меток (по IEEE 802.12.4) является EUI64. В метках ULUN EUI64 однозначно связан с серийным номером.

CAS_ID не связан с серийными номерами меток и анкеров; используется, потому что система CAS360 в целом не имеет одного меточного серийного номера.

DIST_CM5int16Дистанция до метки, см
BEARER6int (enum)

Носитель метки:  0-Generic, 1-Person, 2-Vehicle, 3-Stationary

Опционально, при отсутствии =Generic

SECTOR_DEG

SECTOR_256

7

8

array_uint16[2]

array_uint8[2]

Сектор [ dir angle ], градусы 

Сектор [ dir angle ], в 1/256 круга (1.40625 градуса)

dir - центральное направление сектора, angle - размах сектора

Отсчет вправо от направления вперед транспортного средства (на экране CAS360 по часовой стрелке от направления вверх)

Опционально, при отсутствии – сектор не определен (полный круг)

  • No labels

15 Comments

  1. Eugenia Kalnina

    Нет описания  способа получения этих данных по разным каналам.  Предварительная договоренность была про бинарник, передаваемый по HTTP с типоп application/cbor. Это актуально?

    1. Dmitry Matytsin

      Да, вот описание же есть:

      "по IP-сети (LTE) на заданные в конфигурации HTTPS-сервер и его контекст. Upload бинарных данных с типом Content-Type: application/cbor"

      1. Eugenia Kalnina

        ага, пропустила. 

  2. Oleg Tabarovsky

    Evgeniy Emelyanov Нужно описать требования к серверу: 1) какие методы поддерживаются ? 2) какие endpoints ? 3) коды возврата 4) нужна ли поддержка блочного режима ?

    1. Evgeniy Emelyanov

      Я так понимаю, требования к CoAP серверу?

      1. Конкретно для мессенджера нужно поддерживать метод POST. Хотя какая серверу разница, все надо поддерживать.
      2. Тут не понял. Какие endpoints бывают? Я думаю, будет один endpoint в LAN. Или о чем вопрос?
        А, ну еще лора есть, для нее, наверное, отдельный endpoint нужен
        И еще LTE, тут не знаю, тот же LANовский будет работать, или отдельный.
      3. Коды возврата в хендлерах образуются, серверу их специально поддерживать, вроде как, не нужно. Конкретно мессенджеру нужно отвечать 2.04 (RFC7252 5.8.2) или коды ошибок, соответствующие ошибкам
      4. Блочный режим мессенджеру не нужен, а вообще – не знаю. Лучше пусть будет.

      Конкретно для мессенджера запрос-ответ я подробнее позже опишу, когда сделаю его.

      1. Eugenia Kalnina

        1. все или не все поддерживать серверу зависит от задач, которые от сервера требуются. По умолчанию методы и произвольные контексты не поддерживаются
        2. endpoints это контекст на который клиент будет передавать сообщение, он должен быть известен иначе будет 404 возвращаться.
        1. Evgeniy Emelyanov

          1. Ну, понятно. Пока нужен POST. Payload в нем опишу попозже, не готово еще.
          2. В libcoap endpoint это немного не то, а контекст называется ресурс. Конкретный контекст для мессенджера надо придумать. Предлагаю '/msg'
          1. Eugenia Kalnina

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

  3. Eugenia Kalnina

    Если формат не COAP_MEDIATYPE_APPLICATION_CBOR будет BadRequest (400) возвращаться

    1. Evgeniy Emelyanov

      Хорошо

  4. Oleg Tabarovsky

    Evgeniy Emelyanov как Uptime может быть идентификатором системы ? Если он меняется каждый раз.

    1. Evgeniy Emelyanov

      Он и не является. HEADER::UPTIME это часть заголовка, но не идентификатор. Это опорное значение для пересчета Uptime в событиях в этом сообщении в реальное время.

      1. Oleg Tabarovsky

        Тогда как понимать фразу перед табличкой в разделе HEADER - Множественные Key это альтернативы, придет какой-то один ?

        1. Evgeniy Emelyanov

          Множественные это которые в одной клеточке несколько

          1. Oleg Tabarovsky

            Увидеть бы там еще границы этих клеточек. Я бы явно написал что casid или serial