ГОСТ Р ИСО/МЭК 24730-1-2017 Информационные технологии (ИТ). Системы позиционирования в реальном времени (RTLS). Часть 1. Прикладной программный интерфейс (API)

     5.2 Общие положения

Структурная схема системы RTLS должна иметь соединение "Text over Socket", чтобы клиент по протоколу TCP/IP мог подключаться и в режиме реального времени получать поток сообщений от системы RTLS.

Сообщения отделяются друг от друга знаками <CR><LF> для облегчения отображения консоли. Формат поля отделяется запятыми.

Протокол "Text over Socket" - это минимальное обязательное требование. Если реализованы дополнительные транспортные протоколы, такие как HTTP и JMS, тогда должны быть использованы текстовый формат или XML. Если реализованы REST или SOAP, тогда необходимо использовать формат XML. Текстовый формат включает в себя поля, разделенные запятыми, тогда как формат XML включает в себя сокращенные XML-теги. Оба формата описаны в настоящем стандарте.

________________

Extensible Markup Language (XML) 1.0, (Third Edition), W3C Recommendation, World Wide Web Consortium (W3C), 04 February 2004. (http://www.w3.org/TR/2004/REC-xml-20040204/).

SOAP Version 1.2 Part0: Primer, W3C Recommendation, World Wide Web Consortium (W3C), 24 June 2003, (http://www.w3.org/TR/2003/REC-soap12-part0-20030624/).

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

Задачей настоящего стандарта является обеспечение передачи 3000 сообщений в секунду и больше. Несмотря на то, что во многих приложениях объем в 3000 сообщений в секунду может и не понадобиться, минимальный API систем RTLS должен его поддерживать, потому что существующее на текущий момент применение меток с 3,000 блинк-посылками на частоте 1 Гц может с легкостью поддерживать такое количество сообщений. При интенсивности фильтрования и/или нацеленности информационных систем и программного обеспечения на управление большими объемами данных, REST, SOAP и другие методы передачи сообщений могут обеспечить дополнительную функциональность. Применение текстового формата с разделением запятыми обосновано при поддержке высокой скорости передачи данных, потому что данный формат не является избыточным и позволяет методам передачи сообщений функционировать на средних и высоких скоростях.

Представленный API или протокол называется "формат сообщений простого определения места нахождения" (SLMP, Simple Location Message Protocol). Обязательный формат, разделенный запятыми, называется "протокол сообщений простого определения места нахождения" (SLMF, Simple Location Message Format). Для отдельных транспортных средств SLMF-сокеты ("SLMF-Sockets") - это обязательный совместимый с TCP/IP интерфейс/API протокола SLMP, как, например, SLMF-HTTP - это дополнительный интерфейс/API, поддерживающий HTTP, как элементарный сервис REST систем RTLS. Реализация SLMP может дополнительно включать в себя формат XML.

Клиентское приложение подключается к системе RTLS при помощи TCP/IP-соединения. Система RTLS отвечает потоком сообщений, который прерывается только при закрытии соединения с клиентом.

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

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

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