ГОСТ Р ИСО/МЭК 24730-1-2017

Группа П85

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

Информационные технологии

СИСТЕМЫ ПОЗИЦИОНИРОВАНИЯ В РЕАЛЬНОМ ВРЕМЕНИ (RTLS)

Часть 1

Прикладной программный интерфейс (API)

Information technology. Real-time locating systems (RTLS). Part 1. Application programming interface (API)

ОКС 35.040

Дата введения 2018-12-01

Предисловие

1. ПОДГОТОВЛЕН Научно-исследовательским и испытательным центром биометрической техники МГТУ им. Н.Э.Баумана (НИИЦ БТ МГТУ им. Н.Э.Баумана) и Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении" (ВНИИНМАШ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4, при консультативной поддержке Ассоциации автоматической идентификации "ЮНИСКАН/ГС1 РУС"
2. ВНЕСЕН Техническим комитетом по стандартизации ТК 355 "Технологии автоматической идентификации и сбора данных"
3. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 9 июня 2017 г. N 534-ст
4. Настоящий стандарт идентичен международному стандарту ИСО/МЭК 24730-1:2014* "Информационные технологии. Системы позиционирования в реальном времени (RTLS). Часть 1. Прикладной программный интерфейс (API)" (ISO/IEC 24730-1:2014 "Information technology - Real-time locating systems (RTLS) - Part 1: Application programming interface (API)", IDT).
   При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5. ВВЕДЕН ВПЕРВЫЕ
6. ПЕРЕИЗДАНИЕ. Январь 2019 г.
7. Некоторые элементы настоящего стандарта могут быть объектами патентных прав. Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) не несут ответственности за установление подлинности каких-либо или всех таких патентных прав

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

Введение

Комплекс стандартов ИСО/МЭК 24730 (далее - ИСО/МЭК 24730) имеет общий заголовок "Информационные технологии. Системы позиционирования в реальном времени (RTLS)" и включает в себя следующие части:

• Часть 1: Прикладной программный интерфейс (API);
• Часть 2: Протокол радиоинтерфейса для связи на частоте 2,4 ГГц с использованием расширения спектра методом прямой последовательности (DSSS);
• Часть 21: Протокол радиоинтерфейса для связи на частоте 2,4 ГГц с использованием расширения спектра методом прямой последовательности (DSSS): Передатчики системы RTLS, работающие с одним расширяющим кодом и использующие кодирование данных DBPSK и схему расширения BPSK;
• Часть 22: Протокол радиоинтерфейса для связи на частоте 2,4 ГГц с использованием расширения спектра методом прямой последовательности (DSSS): Передатчики системы RTLS, работающие с несколькими кодами расширения спектра и использующие кодирование данных QPSK и схему расширения QPSK со смещением функции Уолша (WOQPSK);
• Часть 5: Радиоинтерфейс расширения спектра методом линейной частотной модуляции (CSS) для связи на частоте 2,4 ГГц;
• Часть 61: Протокол радиоинтерфейса для сверхширокополосной связи (UWB) с низкой частотой повторения импульсов;
• Часть 62: Протокол радиоинтерфейса для сверхширокополосной связи (UWB) с высокой частотой повторения импульсов.

ИСО/МЭК 24730 определяет несколько протоколов радиоинтерфейсов и единый прикладной программный интерфейс (API) для систем позиционирования в реальном времени ("Real-time locating systems", далее - "системы RTLS") для управления инфраструктурой системы и призван обеспечить конкурентоспособность и улучшить совместимость продуктов на растущем рынке систем RTLS.

Настоящий стандарт устанавливает технические требования к системам RTLS. Для полной совместимости с ИСО/МЭК 24730 система RTLS должна соответствовать настоящему стандарту и одному протоколу радиоинтерфейса, определенному в стандартах ИСО/МЭК 24730.

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

Существуют четыре классификации систем RTLS:

• определение места нахождения объекта при помощи спутника - требуется прямая видимость - точность до 10 м;
• определение места нахождения объекта в контролируемой зоне, например, складское помещение, территория университета, аэропорт - интересующая область оснащается необходимым оборудованием - точность до 3 м;
• определение места нахождения объекта в более ограниченной зоне - интересующая область оснащается необходимым оборудованием - точность десятки сантиметров;
• определение места нахождения объекта над земной поверхностью с использованием установленных на поверхности Земли приемников, например, вышек сотовой связи - точность 200 м.

Существует два дополнительных метода определения места нахождения отдельных объектов или предметов, которые основываются на технологии RFID:

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

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

• время прохождения сигнала (Time of Flight) дальномерных систем;
• амплитуда/триангуляция по мощности входного сигнала;
• разница между моментами времени поступления сигнала (Time Difference of Arrival - TDoA);
• сотовая триангуляция;
• спутниковая мультилатерация;
• угол (направление) приема сигнала (Angle of Arrival - АоА).

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

Настоящий стандарт определяет прикладной программный интерфейс (API), необходимый для использования в системах RTLS.

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

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

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

В настоящем стандарте "точка" используется для отделения дробной части числа после создания выходного файла API с расширением .csv, потому что "запятая" используется для разделения значений.

Международный стандарт ИСО/МЭК 24730-1 подготовлен подкомитетом N 31 "Автоматическая идентификация и технологии сбора данных" Совместного технического комитета N 1 ИСО/МЭК "Информационные технологии" (ISO/IEC JTC 1/SC 31).

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

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

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

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

ISO/IEC 15963 Information technology - Radio frequency identification for item management - Unique identification for RF tags (Информационные технологии. Радиочастотная идентификация для управления предметами. Уникальная идентификация радиочастотных меток)

ISO/IEC 19762 Information technology - Automatic identification and data capture (AIDC) techniques - Harmonized vocabulary (Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь)

IEEE Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48™) (Руководство по использованию 48-битного расширенного уникального идентификатора)

IEEE Guidelines for 64-bit Global Identifier (EUI-64™) Registration Authority (Руководство по использованию 64-битного расширенного уникального идентификатора. Органы регистрации)

Extensible Markup Language (XML) 1.0, (Third Edition), W3C Recommendation, World Wide Web Consortium (W3C), 04 February 2004(Расширяемый язык разметки (XML) 1.0, (Третье издание), рекомендации W3C, Консорциум Всемирной паутины (W3C), 4 февраля 2004 года)

SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C Recommendation, World Wide Web Consortium (W3C), 27 April 2007 (SOAP Версия 1.2. Часть 1: Программная платформа для передачи сообщений (Второе издание), рекомендации W3C, Консорциум Всемирной паутины (W3C), 27 апреля 2007 года).

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

В настоящем стандарте применены термины в соответствии с комплексом стандартов ИСО/МЭК 19762, а также следующие термины с соответствующими определениями:

3.1 поле (field): Элемент записи данных, в котором хранится информация, содержащая одну и более характеристики блинк-посылки метки.

3.2 XML-тег (XML tag): Дескриптор (именованная метка, маркер), определяющий содержимое в XML-документе.

3.3 постоянное подключение (persistent connection): Сетевое соединение между сервером и клиентской частью, которое остается открытым для передачи данных на прикладном уровне или для запроса на установление соединения даже после отправки на прикладном уровне сообщения об ошибке соединения.

3.4 статус метки (tag status): Обязательные поля, содержащие сообщение определения места нахождения и не включающие в себя поле "Source" и поле "Format".

4 Сокращения

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

API - прикладной программный интерфейс (Application Programming Interface);

ASCII - американский стандартный код для обмена информацией (American Standard Code for Information Interchange);

CR - управляющий знак набора ASCII, обозначающий операцию возврата печатающей головки (каретки) (ASCII Carriage Return);

EUI - расширенный уникальный идентификатор (Extended Unique Identifier);

JMS - стандарт промежуточного программного обеспечения для рассылки сообщений, позволяющий приложениям, выполненным на платформе Java ЕЕ, создавать, посылать, получать и читать сообщения (Java Messaging Service);

HTTP - протокол передачи гипертекста (HyperText Transfer Protocol);

HTTPS - протокол передачи гипертекста с защитой (HyperText Transfer Protocol Secure);

LF - управляющий знак набора ASCII, обозначающий место перевода строки, т.е. продолжение печати текста с новой строки или уже на следующей странице (ASCII Line Feed);

OUI - уникальный идентификатор организации (Organizationally Unique Identifier);

REST - метод взаимодействия компонентов распределенного приложения в глобальной сети Интернет (Representational State Transfer);

Система RTLS - система позиционирования в реальном времени (Real Time Locating System);

S-HTTP - защищенный протокол передачи гипертекста (Secure HyperText Transfer Protocol);

SLMF - формат сообщений простого определения места нахождения (Simple Location Message Format);

SLMP - протокол сообщений простого определения места нахождения (Simple Location Message Protocol);

SOAP - простой протокол доступа к объектам (Simple Object Access Protocol);

SSL- протокол безопасных соединений (Secure Sockets Layer);

TDoA - разница между моментами времени поступления сигнала (Time Difference Of Arrival);

TCP/IP - набор сетевых протоколов передачи данных, используемых в сетях, включая глобальную сеть Интернет (Transmission Control Protocol/Internet Protocol);

XML - расширяемый язык разметки (eXtensible Markup Language);

XSD - язык описания структуры XML-документа (XML Schema Definition).

5 Связь

5.1 Назначение

Целью программного обеспечения API системы RTLS является обеспечение простого минимального интерфейса, который облегчает внедрение и ввод в эксплуатацию как системы RTLS, так и прикладной программы. Целью также является обеспечение быстрой передачи сообщений любому клиентскому приложению, подключенному к системе RTLS. Кроме того, поток сообщений должен быть удобочитаемым и легко интерпретируемым.

API должен поддерживаться устройством с минимальной функциональностью, являющимся "устройством сбора и передачи данных" ("collection and forwarding device") без обязательного постоянного хранения данных на сервере и без базы данных.

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

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

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

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

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

Использование 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, представленный в настоящем стандарте, поддерживает несколько одновременных клиентских подключений.

5.3 Конфигурация потока сообщений

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

5.4 Безопасность

Протоколы системы безопасности аппаратуры обмена сообщениями; системы RTLS не рассматриваются в настоящем стандарте, потому что вопросы безопасности можно переадресовать к существующим стандартам по безопасности и технологиям на коммуникационных уровнях, основанных на предпочтениях и стратегии индивидуальных заказчиков. Например, при соединении по протоколу TCP/IP используется протокол системы безопасности SSH, который легко реализовать (совместимо с настоящим стандартом). Аналогично, протоколы системы безопасности, такие как HTTPS и S-HTTP, также могут быть реализованы, как и вышеуказанный протокол.

5.5 Цель

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

5.6 Независимость от языка

API, представленный в настоящем стандарте, определяет независимый от языка программирования интерфейс по отношению к сервису RTLS. Это достигается использованием стандартизованного протокола производственной (вычислительной) сети "Text over Socket" (TCP/IP) для соединения с сервисом RTLS.

5.7 Архитектура

На рисунке 1 описан API обмена сообщениями между клиентским приложением и системой RTLS. В настоящем стандарте API допускает несколько клиентских подключений, таким образом API поддерживает состояние соединения TCP/IP для каждого клиента.

5.8 SLMP сообщения

В данном подразделе описаны сообщения, которые используются в настоящем стандарте. Каждый тип сообщения включает в себя набор полей, которые поставщик системы RTLS реализует в соответствии с определениями, приведенными в настоящем стандарте. Все данные полей и наименования XML-тегов, которые подробно определены в настоящем стандарте, чувствительны к регистру.

5.8.1 Типы данных

Типы данных, описанные в данном пункте, относятся к полям, связанными с сообщениями, определенными в настоящем стандарте. Для сообщений определения места нахождения (Locate message) поставщик системы RTLS может дополнительно включать в состав поля, не описанные в настоящем стандарте. Для таких полей поставщик может выбирать тип данных по своему усмотрению.

DateTime

Данный тип данных представляет собой формат даты и времени (date time format) аналогично международному стандарту ИСО 8601: YYYY-MM-DDThh:mm:ss-hh:mm.

Год в виде YYYY-MM-DD

Месяц в виде YYYY-MM-DD

День в виде YYYY-MM-DD

"Т" показывает место начала отображения времени "Time will follow".

Часы в виде hh:mm:ss

Минуты в виде hh:mm:ss

Секунды в виде hh:mm:ss

Плюс или минус смещение от универсального глобального времени (по Гринвичу) в часах и минутах (-hh:mm or +hh:mm).

Пример - 2010-11-24Т09:07:04-08:00//для стандартного тихоокеанского времени.

Необходимо отметить, что дробная часть с точностью до одной десятой миллисекунды (.0001 с) может быть добавлена к элементу времени низшего порядка. Например, чтобы показать 14 ч, 30 мин и 12.359 с, необходимо представить это время как 14:30:12.359.

Double

Данный тип данных представляет собой числовой формат с плавающей точкой, включающий в себя дополнительно закодированный десятичный разделитель, и может отображаться с экспонентой и мантиссой или без них. Примеры включают в себя: 2345.334, -98.7, 1.0, 4, 0.0, 0.5, 9.87+Е8.

Диапазон значений поля типа "Double": от 1.7Е-308 до 1.7Е+308, максимальная длина строки - 256 символов.

HexBinary

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

Максимальная длина поля для типа поля "HexBinary" - 256 байт.

Integer

Данный тип данных представляет собой числа, которые могут быть записаны без дробной или десятичной части и входят в набор {..., -2, -1, 0, 1, 2, ...}.

Диапазон значений поля типа "Integer": от -2,147,483,648 до 2,147,483,647.

String

Данный тип данных представляет собой набор ASCII-символов, ограниченный следующими символами:

А, В, С, D, Е, F, G, Н, I, J, K, L, М, N, О, Р, Q, R, S, Т, U, V, W, X, Y, Z, а, b, с, d, е, f, g, h, i, j, k, I, m, n, o, p, q, r, s, t, u, v, w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, space, !, (,), [,], *, #, $, %, &, +, -, _, ., /, ?, =

Максимальная длина поля для поля типа "String" - 256 символов.

5.8.2 Заголовок сообщения (Header Message)

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

Последовательность полей:

<Appliance_ID>, SLMF, <SLMF_version>, <SLMF_vendor_version>, <Greeting> <CR> <LF>

Поля:

Appliance_ID (обязательное поле)

XML-тег:	<aid>