ГОСТ Р ИСО/МЭК 18000-7-2012 Информационные технологии. Идентификация радиочастотная для управления предметами. Часть 7. Параметры активного радиоинтерфейса для связи на частоте 433 МГц

ГОСТ Р ИСО/МЭК 18000-7-2012

Группа П85

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

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

ИДЕНТИФИКАЦИЯ РАДИОЧАСТОТНАЯ ДЛЯ УПРАВЛЕНИЯ ПРЕДМЕТАМИ

Часть 7

Параметры активного радиоинтерфейса для связи на частоте 433 МГц

Information technologies. Radio frequency identification for item management. Part 7. Parameters for active air interface communications at 433 MHz

ОКС 35.040

Дата введения 2013-07-01

Предисловие

1 ПОДГОТОВЛЕН ООО "НТЦ "Альфа-1" при участии Ассоциации автоматической идентификации "ЮНИСКАН/ГС1 РУС" на основе выполненного ООО "НТЦ "Альфа-1" аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 355 "Технологии автоматической идентификации и сбора данных и биометрия"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2012 г. N 1428-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 18000-7:2009* "Информационные технологии. Радиочастотная идентификация для управления предметами. Часть 7. Параметры активного радиоинтерфейса для связи на частоте 433 МГц" (ISO/IEC 18000-7:2009 "Information technology - Radio frequency identification for item management - Part 7: Parameters for active air interface communications at 433 MHz").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .

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

Перевод на русский язык наименований команд, сигналов, ошибок, физических параметров и параметров управления множественным доступом по ИСО/МЭК 18000-7 приведен в дополнительном приложении ДБ

5 ВВЕДЕН ВПЕРВЫЕ

6 Следует обратить внимание на то, что некоторые элементы настоящего стандарта могут быть объектом патентных прав. ИСО и МЭК не несут ответственность за установление подлинности каких-либо или всех таких патентных прав


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте национального органа Российской Федерации по стандартизации в сети Интернет (gost.ru)

Введение

Введение

Настоящий стандарт применяется к устройствам радиочастотной идентификации (РЧИ), работающим на частоте 433 МГц, осуществляющим применение радиоинтерфейса в аппаратуре беспроводных бесконтактных информационных систем при их использовании для управления предметами. Типичные условия применения предусматривают работу на дальностях более одного метра.

Система РЧИ включает в себя системное оборудование и оборудование радиочастотной идентификации (устройство считывания/опроса и радиочастотные метки). Системное оборудование использует программное обеспечение, которое управляет взаимодействием с оборудованием РЧИ. Оборудование РЧИ включает в себя два основных компонента: радиочастотные метки и устройства считывания/опроса (УСО). Радиочастотные метки предназначены для закрепления на предметах, которыми необходимо управлять пользователю. Они должны обеспечивать хранение серийного номера радиочастотной метки и других данных, относящихся к радиочастотной метке или изделию, и передачу этой информации УСО. УСО является устройством, осуществляющим связь с радиочастотной меткой в ее радиочастотном диапазоне. УСО управляет протоколом радиоинтерфейса, считывает информацию с радиочастотных меток, в некоторых случаях выдает радиочастотным меткам команды записи данных, а также обеспечивает доставку сообщений и достоверность данных. В данной системе РЧИ используются активные радиочастотные метки.

Системы РЧИ, удовлетворяющие требованиям настоящего стандарта, должны выполнять следующий минимальный набор функций:

- идентификацию радиочастотных меток в рабочей области УСО;

- считывание данных;

- запись данных или обработку устройств с записями только для чтения;

- выбор по группам или адресам;

- поэтапную обработку множества радиочастотных меток в рабочей области УСО;

- обнаружение ошибок.

Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) обращают внимание на то, что соответствие настоящему стандарту может подразумевать необходимость использования патентов в области технологии радиочастотной идентификации, указанных в 6.2. ИСО и МЭК не рассматривают вопросов подтверждения, срока действия и области применения указанных патентных прав.

Владельцы указанных патентных прав гарантируют ИСО и МЭК готовность вести переговоры с обратившимися к ним лицами о предоставлении лицензий на разумных и недискриминационных условиях. При наличии таких гарантий заявления владельцев патентных прав регистрируются в ИСО и МЭК.

Информация о заявленных патентах приведена в таблице ниже.

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

Пояснения к тексту настоящего стандарта приведены в виде сносок и выделены курсивом.

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

Настоящий стандарт устанавливает требования к радиоинтерфейсу для систем радиочастотной идентификации (РЧИ) с активными радиочастотными метками, работающих на частоте 433 МГц и используемых для управления предметами, и содержит общее техническое описание устройств РЧИ, которое может быть использовано при разработке стандартов по применению систем радиочастотной идентификации. Настоящий стандарт должен способствовать обеспечению совместимости и улучшению способности к взаимодействию устройств растущего рынка РЧИ в международном масштабе.

Настоящий стандарт определяет следующие параметры прямой и обратной линий связи, образующих систему РЧИ устройств (но ими не ограничивается): рабочую частоту; допустимое отклонение частоты рабочего канала; ширину полосы частот канала; максимальную мощность; паразитные излучения; вид модуляции; коэффициент модуляции; метод кодирования данных; скорость передачи данных; допустимое отклонение скорости передачи данных; порядок передачи битов и, где это необходимо, рабочие каналы, скорость скачкообразного изменения частоты, последовательность скачкообразного изменения частоты, расширяющую последовательность, скорость передачи единичных элементов сигнала. Настоящий стандарт также определяет протоколы обмена данными, которые использует радиоинтерфейс.

2 Соответствие стандарту

Правила оценки соответствия устройств РЧИ настоящему стандарту определены в ИСО/МЭК ТО 18047-7.

2.1 Общие требования к радиоизлучению

Изготовители устройств, утверждая об их соответствии требованиям настоящего стандарта, должны заявить о своей ответственности в том, что радиочастотное излучение не превышает максимально допустимых пределов воздействия, рекомендованных IEEE С95.1:2005 или ICNIRP в соответствии с МЭК 62369-1. Если изготовитель устройств не определился, требованиям каких рекомендаций необходимо указать соответствие, то изготовитель должен заявить о своей ответственности за их соответствие ограничениям ICNIRP.

2.2 Радиочастотное излучение и чувствительность медицинского оборудования

Изготовители устройств, утверждающие о соответствии требованиям настоящего стандарта, должны заявить о своей ответственности за удовлетворение требованиям МЭК 60601-1-2.

2.3 Структура команд и возможность расширений

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

Спецификации команд и их интерпретации полностью определены в соответствующих разделах настоящего стандарта.

Каждая команда определена в качестве обязательной или дополнительной.

Разделы настоящего стандарта также предусматривают возможность использования команд пользователя и изготовителя.

2.4 Обязательные команды

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

2.5 Дополнительные команды

Дополнительными командами являются команды, которые определены как таковые в настоящем стандарте. УСО должны иметь технические возможности для поддержки всех дополнительных команд, которые определены как таковые в настоящем стандарте (хотя это может не предусматриваться установками при отсутствии необходимости). Радиочастотные метки могут поддерживать или не поддерживать выполнение дополнительных команд.

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

2.6 Команды пользователя

Команды пользователя могут быть разрешены при применении настоящего стандарта, но настоящий стандарт не определяет их.

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

2.7 Команды изготовителя

Команды изготовителя могут быть разрешены при применении настоящего стандарта, но настоящий стандарт не определяет их.

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

Все команды изготовителя должны быть заблокированы до того, как радиочастотные метки покинут предприятие изготовителя. Все команды изготовителя предназначены для целей производства и не должны использоваться в развернутых для эксплуатации системах РЧИ.

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

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

ИСО/МЭК 8859-1 Информационные технологии. Наборы 8-битовых однобайтовых кодированных графических знаков. Часть 1. Латинский алфавит N 1 (ISO/IEC 8859-1, Information technology - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1)

ИСО/МЭК 15459 (все части) Информационные технологии. Уникальные идентификаторы (ISO/IEC 15459 (all parts), Information technology - Unique identifiers)

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

ИСО/МЭК ТО 18047-7 Информационные технологии. Методы испытаний на соответствие устройств радиочастотной идентификации. Часть 7. Методы испытаний активного радиоинтерфейса для связи на частоте 433 МГц (ISO/IEC TR 18047-7, Information technology - Radio frequency identification device conformance test methods - Part 7: Test methods for active air interface communications at 433 MHz)

ИСО/МЭК 19762-1 Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь. Часть 1. Общие термины в области АИСД [ISO/IEC 19762-1, Information technology - Automatic identification and data capture (AIDC) techniques - Harmonized vocabulary - Part 1: General terms relating to AIDC]

ИСО/МЭК 19762-3 Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь. Часть 3. Радиочастотная идентификация (РЧИ) [ISO/IEC 19762-3, Information technology - Automatic identification and data capture (AIDC) techniques - Harmonized vocabulary - Part 3: Radio frequency identification (RFID)]

МЭК 62369-1, Изд.1.0, Определение воздействия на человека электромагнитных полей от устройств малого радиуса действия (SRD) при различных применениях в диапазоне частот от 0 ГГц до 300 ГГц. Часть 1. Поля, создаваемые устройствами, используемыми для электронного слежения за предметами, радиочастотной идентификации и в подобных системах [IEC 62369-1, Ed. 1.0, Evaluation of human exposure to electromagnetic fields from short range devices (SRDs) in various applications over the frequency range 0 GHz to 300 GHz - Part 1: Fields produced by devices used for electronic article surveillance, radio frequency identification and similar systems]

МЭК 60601-1-2 Медицинское электронное оборудование. Часть 1-2. Общие требования по основополагающей безопасности и важнейшим эксплуатационным характеристикам. Сопутствующий стандарт. Электромагнитная совместимость. Требования и испытания (IEC 60601-1-2, Medical electrical equipment - Part 1-2: General requirements for basic safety and essential performance - Collateral standard: Electromagnetic compatibility - Requirements and tests)

Рекомендации ICNIRP Рекомендации по ограничению воздействия переменных во времени электрических, магнитных и электромагнитных полей (до 300 ГГц), Международная комиссия по защите от неионизирующего излучения [ICNIRP Guidelines, Guidelines for limiting exposure to time-varying electric, magnetic, and electromagnetic fields (up to 300 GHz), International Commission on Non-Ionizing Radiation Protection]
_______________
ICNIRP (The International Commission on Non-Ionizing Radiation Protection) - Международная комиссия по защите от неионизирующего излучения.


IEEE C95.1:2005 Стандарт IEEE по безопасным уровням воздействия на человека радиочастотных электромагнитных полей от 3 кГц до 300 ГГц (IEEE С95.1:2005, IEEE Standard for Safety Levels with Respect to Human Exposure to Radio Frequency Electromagnetic Fields, 3 kHz to 300 GHz)
_______________
IEEE (Institute of Electrical and Electronics Engineers, Inc.) - Институт инженеров по электротехнике и радиоэлектронике. ИИЭР - международная организация по стандартизации.

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

В настоящем стандарте применены термины и определения, установленные в ИСО/МЭК 19762-1 и ИСО/МЭК 19762-3.

5 Обозначения и сокращения

В настоящем стандарте использованы обозначения и сокращения, установленные в ИСО/МЭК 19762-1 и ИСО/МЭК 19762-3.

6 Технические требования к активной узкополосной системе на частоте 433,92 МГц

6.1 Физический (сигнальный) уровень

Радиочастотная линия связи между УСО и радиочастотной меткой использует узкую полосу частот в диапазоне УВЧ со следующими номинальными значениями параметров:

- несущая частота - 433,92 МГц;

- тип модуляции - частотная манипуляция (FSK);

- девиация частоты - ±50 кГц;

- низкий логический уровень символа - (50) кГц;

- высокий логический уровень символа - (50) кГц;

- частота передачи данных - 27,7 кГц;

- сигнал пробуждения (сигнал "Wake Up") - периодический сигнал прямоугольной формы (меандр) с частотой модуляции 31,25 кГц и следующий за ним периодический сигнал прямоугольной формы (меандр) с частотой модуляции 10 кГц.

Подробные требования к физическому (сигнальному) уровню см. в 6.6.

Для перевода в активное состояние всех радиочастотных меток, находящихся в рабочей области УСО, сигнал "Wake Up" должен передаваться, как минимум, 2,45 с. Сигнал "Wake Up" должен состоять из модулированного меандром с частотой 31,25 кГц заголовка ("Wake Up Header") длительностью от 2,35 до 4,8 с, за которым немедленно следует подзаголовок ("Co-Header") длительностью 0,1 с, имеющий модуляцию меандром с частотой 10 кГц.

При регистрации и выполнении сигнала "Wake Up" все радиочастотные метки должны перейти в состояние готовности "Ready" и ждать команд УСО (см. рисунок 1). Радиочастотные метки могут находиться в одном из двух состояний - "Ready"/"Awake" (состояние готовности или пробуждения) или "Asleep" (спящее состояние). В состоянии "Ready" радиочастотные метки должны принять действительную команду от УСО и дать на нее требуемый ответ. В состоянии "Asleep" радиочастотная метка игнорирует все команды.

Рисунок 1 - Сигнал пробуждения "Wake Up"

Рисунок 1 - Сигнал пробуждения "Wake Up"

Радиочастотная метка, выведенная из спящего состояния, остается активной, как минимум, 30 с после получения последнего действительного пакета сообщения, содержащего действительный идентификатор протокола (Protocol ID), код команды (Command Code) и значение кода CRC, если до истечения этого времени не получена команда УСО перейти в спящее состояние. Если в течение 30 с не поступает сформированное должным образом сообщение с командой, то радиочастотная метка должна перейти в спящее состояние и больше не должна отвечать на команды УСО.

Связь между УСО и радиочастотной меткой осуществляется по типу ведущего и ведомого ("Master-Slave"), при этом УСО инициирует сеанс связи, а затем ждет ответ от радиочастотной метки. Передача ответов от множества радиочастотных меток определяется алгоритмом опроса, описанным в 6.4.

6.2 Уровень линий передачи данных

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

Данные по линии связи между УСО и радиочастотной меткой передаются в формате пакета. Пакет состоит из преамбулы, байта данных и сигнала окончания пакета. Последние два изменения уровня сигнала в преамбуле являются признаком ее окончания и начала первого байта данных. Те же два изменения уровня сигнала в преамбуле также указывают на источник пакета данных. Данные передаются в формате манчестерского кода. Порядок передачи должен быть таким: первым передается старший байт, а внутри байта первым передается младший бит. На рисунке 2 показаны логические уровни синхронизации передачи данных преамбулы и первого байта пакета.

Рисунок 2 - Синхронизация передачи данных по времени

Примечание - Порядок передачи данных: первым передается старший байт, внутри байта первым передается младший бит. Первому периоду преамбулы предшествует сигнал низкого логического уровня длительностью 15 мкс. На рисунке в байте показан код "0хС6".

Рисунок 2 - Синхронизация передачи данных по времени

6.2.2 Преамбула

Преамбула должна содержать 20 периодов длительностью 60 мкс. Каждый такой период состоит из сигнала высокого логического уровня длительностью 30 мкс и сигнала низкого логического уровня длительностью 30 мкс. Затем идут два конечных изменения уровня сигнала, которые определяют направление передачи данных. Так, перепад высокого уровня сигнала длительностью 42 мкс на низкий уровень сигнала длительностью 54 мкс указывает на передачу данных от радиочастотной метки к УСО, а перепад высокого уровня сигнала длительностью 54 мкс на низкий уровень сигнала длительностью 54 мкс - на передачу данных от УСО к радиочастотной метке (см. рисунок 2).

6.2.3 Байты данных

Байты данных должны передаваться в формате манчестерского кода, каждый байт содержит 8 битов данных и один стоповый бит. Битовый период равен 36 мкс, общий байтовый период - 324 мкс. Спад сигнала в середине бита является признаком значения "0", фронт сигнала - признаком "1". Стоповый бит кодируется как нулевой.

6.2.4 Признак конца пакета

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

6.2.5 Формат сообщения от УСО к радиочастотной метке

Радиочастотные метки должны распознавать получаемые от УСО сообщения в формате, описанном в таблицах 1 и 2.


Таблица 1 - Формат команды УСО ко всем радиочастотным меткам (общая команда)

Таблица 2 - Формат команды УСО к конкретной радиочастотной метке (частная команда)

6.2.5.1 Идентификатор протокола (Protocol ID)

Поле идентификатора протокола (Protocol ID) позволяет осуществлять разработку различных стандартов применения, используя за основу положения настоящего стандарта ("производные стандарты применения"). Все производные стандарты применения должны использовать одинаковый протокол физического (сигнального) уровня, но структура (поля) команд и ответов, а также набор команд могут отличаться в зависимости от применения. В настоящем стандарте определены три основные команды: "Collection with Universal Data Block", "Sleep" и "Sleep All But", которые должны поддерживаться всеми производными стандартами. Все остальные команды в соответствии с требованиями настоящего стандарта должны поддерживаться устройствами, соответствующими настоящему стандарту, но необязательны для поддержки устройствами, соответствующими производным стандартам применения.

При передаче УСО сигнала пробуждения "Wake Up" все радиочастотные метки, поддерживающие требования к радиоинтерфейсу настоящего стандарта и производных стандартов применения, должны перейти в активное состояние.

УСО может передавать различные команды в зависимости от применения. Для инвентаризации всех активных радиочастотных меток в рабочей области УСО должно выдать команду сбора данных "Collection", определенную в настоящем стандарте. На эту основную команду сбора данных "Collection" должны отвечать все радиочастотные метки, поддерживающие как настоящий стандарт, так и производные стандарты применения. Радиочастотные метки должны отвечать на команду "Collection" с использованием форматов ответа, устанавливаемых в стандарте на применяемые радиочастотной меткой уровни линий передачи данных (в настоящем стандарте или производных стандартах). Также радиочастотные метки должны выполнять команды "Sleep" и "Sleep All But", определенные в настоящем стандарте. Совместимость настоящего стандарта и производных стандартов проиллюстрирована в приложении А.

6.2.5.2 Опции пакета (Packet Options)

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

- только для частной команды: значение бита 1 в поле опций пакета установлено на "1";

- только для общей команды: значение бита 1 в поле опций пакета установлено на "0".


Таблица 3 - Поле опций пакета

Зарезервированные биты предназначены для использования в будущем. Они имеют нулевое значение по умолчанию.

6.2.5.3 Длина пакета (Packet Length)

Поле длины пакета используется для указания длины сообщения (в байтах) с начала идентификатора протокола до поля кода CRC включительно.

6.2.5.4 Идентификатор изготовителя радиочастотной метки (Tag Manufacturer ID)

Идентификатор изготовителя радиочастотной метки - это уникальный идентификатор, присваиваемый каждому изготовителю радиочастотных меток. Идентификатор изготовителя радиочастотной метки представляет собой шестнадцатибитовый код, присвоенный органом регистрации в соответствии с ИСО/МЭК 15963. Указанный шестнадцатибитовый код состоит из кода категории по ИСО/МЭК 15963 "0001 0001" (старший байт), а также восьмибитового идентификатора организации, присваивающей идентификатор UID "хххххххх" (младший байт).
_______________
В настоящем стандарте использовано устаревшее название идентификатора радиочастотной метки - UID. Согласно действующему стандарту ГОСТ Р ИСО/МЭК 15963-2011 идентификатор радиочастотной метки называется TID (от английского "Tag Identifier").


Пример - Если идентификатор организации, присваивающей идентификатор UID, имеет значение "00000100", то идентификатор изготовителя радиочастотной метки будет иметь значение "00010001 00000100".

Формат и содержание идентификатора изготовителя радиочастотной метки должны удовлетворять требованиям к уникальным идентификаторам по ИСО/МЭК 15459-1.

Структура и расположение идентификатора изготовителя радиочастотной метки также описаны в документах ИСО/МЭК 15963 и INCITS 256.

Органом регистрации для ИСО/МЭС 18000-7 является Autoid.org.
_______________
Autoid.org - зарегистрированная торговая марка фирмы "Q.Е. D. Systems" (США), под которой фирма оказывает услуги по присвоению уникальных идентификаторов изготовителей радиочастотных меток, соответствующих требованиям ИСО/МЭК 18000-7. (Для справок и обращений URL - //www.autoid.org.)

6.2.5.5 Серийный номер радиочастотной метки (Tag Serial Number)

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

Идентификатор изготовителя радиочастотной метки и серийный номер радиочастотной метки вместе уникально идентифицируют радиочастотные метки в соответствии с ИСО/МЭК 15963. В этой шестибайтовой комбинации первые два байта представляют идентификатор изготовителя радиочастотной метки, а последующие четыре байта - серийный номер радиочастотной метки.

Пример комбинированной структуры данных из идентификатора изготовителя радиочастотной метки и серийного номера радиочастотной метки - "00010001 00000100 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx".

6.2.5.6 Идентификатор сеанса (Session ID)

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

Значение идентификатора сеанса "0x0000" является резервным и не должно использоваться.

6.2.5.7 Коды команд

Коды команд и соответствующие функции чтения/записи приведены ниже в таблице 4.


Таблица 4 - Коды команд

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

Тип команды указывает на то, является ли команда общей (не включает в сообщение идентификатор изготовителя радиочастотной метки и серийный номер радиочастотной метки) или частной (включает в сообщение идентификатор изготовителя радиочастотной метки и серийный номер радиочастотной метки).

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

6.2.5.8 Аргументы команды

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

6.2.5.9 Код CRC

Контрольная сумма в виде шестнадцатибитового значения рассчитывается для каждого сообщения команды с начальным нулевым значением ("0x0000") по всем байтам данных (исключая преамбулу) от идентификатора протокола до аргументов команды включительно. Расчет ведется в соответствии с рекомендацией CCITT с помощью полинома "х+х+х+1". Значение кода CRC добавляется в соответствующее поле командного сообщения в виде двухбайтового поля. См. "Рекомендации ITU-T V.41 (Извлечения из официальных документов). Кодонезависимая система контроля ошибок, приложение I - Реализация кодирования и декодирования для системы с использованием циклического кода" [ITU-T Recommendation V.41 (Extract from the Blue Book), Code-independent error-control system, Appendix I - Encoding and decoding realization for cyclic code system].
_______________
Международный консультационный комитет по телефонии и телеграфии, МККТТ (фр. Consultatif International et , CCITT) - подразделение Международного союза электросвязи (ITU). С 1995 года этот комитет официально называется ITU-T сектор стандартизации электросвязи Международного союза электросвязи (англ. International Telecommunication Union - Telecommunication sector). CCITT (ITU-T) разрабатывает технические стандарты, известные как "Рекомендации", по всем международным аспектам цифровых и аналоговых коммуникаций.

6.2.6 Формат ответа от радиочастотной метки к УСО

В зависимости от типа сообщения, передаваемого радиочастотной меткой УСО, оно может иметь один из двух форматов. Радиочастотная метка должна всегда отвечать на команду, используя один из форматов ответа, описанных ниже. Исключение составляют случаи, когда радиочастотная метка не должна отвечать УСО, а именно:

- команда, удовлетворяющая требованиям настоящего стандарта, не требует ответа;

- значение кода CRC, принятое радиочастотной меткой в команде, не совпадает со значением кода CRC, рассчитанным радиочастотной меткой для пакета команды;

- общая команда получена с неправильным командным кодом или другой ошибкой;

- радиочастотная метка находится в спящем состоянии.

Существует два возможных формата ответа:

- формат ответа на общую команду;

- формат ответа на частную команду.

6.2.6.1 Формат ответа радиочастотной метки на общую команду

Данный формат сообщения, приведенный в таблице 5, используется в ответе радиочастотной метки, находящейся в рабочей области УСО, на его общую команду. Общие команды см. в таблице 4.


Таблица 5 - Формат ответа на общую команду

В соответствии с таблицей 5 в своем ответе на общую команду радиочастотная метка должна передать идентификатор протокола и следующую информацию:

- статус радиочастотной метки, который указывает несколько параметров: формат ответа, тип радиочастотной метки, наличие сигнала предупреждения (alarm), наличие отказов аппаратуры. Подробнее о статусе метки см. 6.2.6.4;

- длину пакета, которая указывает число байтов в сообщении, начиная с поля идентификатора протокола и до поля кода CRC включительно;

- идентификатор сеанса: идентификатор конкретного УСО. Имеет целое значение от "0x0001" до "0xFFFF". Нулевое значение "0x0000" зарезервировано и не используется;

- идентификатор изготовителя радиочастотной метки: уникальный идентификатор, присвоенный изготовителю;

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

- код команды: код команды, полученной от УСО (см. таблицу 4);

- данные: строка данных, передаваемая радиочастотной меткой в ответ на действительную общую команду УСО. Значение N - длина строки данных в байтах, которая определяется командой. Если радиочастотная метка получает недействительную команду, никакого ответа УСО не передается;

- код CRC: контрольный код в байтах (см. 6.2.5.9).

6.2.6.2 Формат ответа радиочастотной метки на частную команду

Данный формат, приведенный в таблице 6, используется в ответе метки на все частные команды УСО, которые требуют указания изготовителя метки и серийного номера для доступа к конкретной метке. (Частные команды указаны в таблице 4.)


Таблица 6 - Формат ответа радиочастотной метки на частную команду УСО

В соответствии с таблицей 6 в своем ответе на частную команду радиочастотная метка должна передать идентификатор протокола и следующую информацию:

- статус радиочастотной метки, который указывает несколько параметров: формат ответа, тип радиочастотной метки, наличие сигнала предупреждения (alarm), наличие отказов аппаратуры. Подробнее о статусе метки см. 6.2.6.4;

- длину пакета, которая указывает число байтов в сообщении, начиная с поля идентификатора протокола и до поля кода CRC включительно;

- идентификатор сеанса: идентификатор конкретного УСО. Имеет целое значение от "0x0001" до "0xFFFF". Нулевое значение "0x0000" зарезервировано и не используется;

- идентификатор изготовителя радиочастотной метки: уникальный идентификатор, присвоенный изготовителю;

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

- код команды: код команды, полученной от УСО (см. таблицу 4);

- данные: строка данных, передаваемая радиочастотной меткой в ответ на действительную команду УСО. Значение N - длина строки в байтах, определяется командой. Если радиочастотная метка обнаруживает ошибку, в слове статуса метки устанавливается флаг "NACK", а передаваемые данные содержат код ошибки, описанный в 6.2.6.3;

- код CRC: контрольный код в байтах (см. 6.2.5.9).

6.2.6.3 Коды ошибок

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


Таблица 7 - Коды ошибок

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


Таблица 8 - Основной формат сообщения об ошибке

Таким образом, согласно таблице 8 сообщение об ошибке должно содержать следующие данные:

- код ошибки: значение из таблицы 7, указывающее вид ошибки;

- субкод: дополнительное значение, уточняющее природу ошибки и ее специфику. Это поле отсутствует, если вид ошибки не предусматривает наличие субкода. Значения субкодов определены в подразделе описания ошибок, приведенном ниже;

- данные параметров ошибки (Error Parameter Data): байтов данных, где 0, наличие, длина и содержание которых зависят от природы ошибки. Это поле отсутствует, если вид ошибки не предусматривает его наличия. Специфичные для ошибки данные параметров ошибки и длина N этого поля, если используются, определены в подразделах описания ошибок ниже;

- данные изготовителя (Manufacturer Data): байтов данных, где 0, наличие, длина и содержание которых устанавливаются изготовителем радиочастотной метки.

6.2.6.3.1 Ошибка "Invalid Command Code"

В таблице 9 показан формат сообщения об ошибке "Invalid Command Code" (недействительный код команды).


Таблица 9 - Формат сообщения об ошибке "Invalid Command Code"

Это сообщение об ошибке генерируется радиочастотной меткой, если она получила пакет с неопределенным в настоящем стандарте кодом команды и/или субкодом команды.

6.2.6.3.2 Ошибка ""Invalid Command Parameter"

В таблице 10 показан формат сообщения об ошибке "Invalid Command Parameter" (недействительный параметр команды).


Таблица 10 - Формат сообщения об ошибке "Invalid Command Parameter"

В соответствии с таблицей 10 в своем сообщении об ошибке "Invalid Command Parameter" радиочастотная метка должна передать код ошибки и следующую информацию:

- субкод: код, который уточняет характер ошибки. Его значения определены в таблице 11;

- смещение параметра (Parameter Offset): смещение в байтах от начала поля аргументов команды, где была обнаружена ошибка.


Таблица 11 - Субкоды ошибки "Invalid Command Parameter"

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

6.2.6.3.3 Ошибка "Optional Command not Supported"

В таблице 12 показан формат сообщения об ошибке "Optional Command not Supported" (дополнительная команда не поддерживается).


Таблица 12 - Сообщение об ошибке "Optional Command not Supported"

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

6.2.6.3.4 Ошибка "Not Found"

В таблице 13 показан формат сообщения об ошибке "Not Found" (объект не найден).


Таблица 13 - Сообщение об ошибке "Not Found"

В соответствии с таблицей 13 в своем сообщении об ошибке "Not Found" радиочастотная метка должна передать код ошибки и следующую информацию:

- субкод: код, который уточняет характер ошибки. Значения субкода ошибки "Not Found" определены в таблице 14.


Таблица 14 - Субкоды ошибки "Not Found"

6.2.6.3.5 Ошибка "Can't Create Object"

В таблице 15 показан формат сообщения об ошибке "Can't Create Object" (невозможно создать объект).


Таблица 15 - Сообщение об ошибке "Can't Create Object"

В соответствии с таблицей 15 в своем сообщении об ошибке "Can't Create Object" радиочастотная метка должна передать код ошибки и следующую информацию:

- субкод: код, который уточняет характер ошибки. Значения субкода ошибки "Can't Create Object" определены в таблице 16.


Таблица 16 - Субкоды ошибки "Can't Create Object"

Таким образом, при неудачной попытке создать требуемую табличную базу данных будет сгенерирована ошибка по таблице 15.

6.2.6.3.6 Ошибка "Authorization Failure"

В таблице 17 показан формат сообщения об ошибке "Authorization Failure" (отказ авторизации).


Таблица 17 - Сообщение при ошибке "Authorization Failure"

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

6.2.6.3.7 Ошибка "Object is Read-Only"

В таблице 18 показан формат сообщения об ошибке "Object is Read-Only" (объект только для чтения).


Таблица 18 - Сообщение об ошибке "Object is Read-Only"

Данный код ошибки генерируется при попытке осуществить недопустимое изменение данных в памяти метки.

6.2.6.3.8 Ошибка "Operation Failed"

В таблице 19 показан формат сообщения об ошибке "Operation Failed" (сбой операции).


Таблица 19 - Сообщение при ошибке "Operation Failed"

В соответствии с таблицей 19 в своем сообщении об ошибке "Operation Failed" радиочастотная метка должна передать код ошибки и следующую информацию:

- субкод: код, который уточняет характер ошибки. Значения субкода ошибки "Operation Failed" определены в таблице 20.


Таблица 20 - Субкоды ошибки "Operation Failed"

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

6.2.6.3.9 Ошибка "Implementation Dependent"

В таблице 21 показан формат сообщения об ошибке "Implementation Dependent" (ошибка для данной версии).


Таблица 21 - Сообщение при ошибке "Implementation Dependent"

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

6.2.6.3.10 Ошибка "Stale Token"

В таблице 22 показан формат сообщения об ошибке "Stale Token" (недействительный маркер).


Таблица 22 - Сообщение об ошибке "Stale Token"

Данный код ошибки генерируется в том случае, если маркер запроса (Request Token) в команде УСО недействителен ввиду проведения изменения таблицы, к которой относится маркер запроса. Эти изменения включают в себя выполнение следующих команд: "Add Records", "Table Update Records", "Table Update Fields" или "Table Delete Record".

6.2.6.3.11 Ошибка "Boundary Exceeded"

В таблице 23 показан формат сообщения об ошибке "Boundary Exceeded" (переполнение).


Таблица 23 - Сообщение об ошибке "Boundary Exceeded"

В соответствии с таблицей 23 в своем сообщении об ошибке "Boundary Exceeded" радиочастотная метка должна передать код ошибки и следующую информацию:

- субкод: код, который уточняет характер ошибки. Значения субкода ошибки "Boundary Exceeded" определены в таблице 24.


Таблица 24 - Субкоды ошибки "Boundary Exceeded"

Данный код ошибки, представленный в таблице 23, и субкод, представленный в таблице 24, генерируются при попытке осуществить доступ к записи вне установленных пределов.

6.2.6.4 Статус радиочастотной метки (Tag status)

Поле статуса радиочастотной метки показано в таблице 25, оно должно включаться во все сообщения радиочастотной метки, передаваемые УСО.


Таблица 25 - Формат поля статуса радиочастотной метки

Поле статуса радиочастотной метки, показанное в таблице 25, должно содержать следующую информацию:

- поле режима (Mode field): указывает формат ответа радиочастотной метки (ответ на общую или частную команду). Список возможных значений этого поля показан в таблице 26;


Таблица 26 - Формат поля режима (Mode field)
_______________
Вместо заголовка "Формат поля режима (Mode field)" в оригинале ИСО/МЭК 18000-7:2009 приведен заголовок "Формат поля статуса метцки (Tag status)".

- бит сигнала предупреждения (alarm): предназначен быть основным битом статуса, указывающим на возможность отправки сообщения радиочастотной меткой без получения команды. Если значение этого бита установлено на "1", радиочастотной меткой определено состояние способности подачи сигнала предупреждения. Интерпретация, действия по извлечению данных и очистке бита сигнала предупреждения определяются поставщиком радиочастотной метки;

- бит подтверждения: значение "0" указывает на получение радиочастотной меткой действительной команды (все поля действительны, и код CRC имеет правильное значение) от УСО и успешное ее выполнение. Если данный бит равен "1", команда была недействительна или радиочастотная метка обнаружила ошибку при выполнении команды. Следует отметить, что при ошибочном коде CRC радиочастотная метка не передает ответ (см. 6.2.6);

- тип радиочастотной метки: значение, которое присваивается и является значимым только для изготовителя радиочастотной метки. Данное значение может использоваться изготовителем для указания специфических свойств радиочастотной метки;

- сервисный бит: значение "1" указывает, что радиочастотная метка обнаружила ошибки в работе аппаратуры. Дополнительная информация о характере ошибки может быть получена с помощью универсального блока данных состояния отказов аппаратуры (Hardware Fault Status UDB).

6.3 Команды для радиочастотных меток

6.3.1. Команда "Collection with Universal Data Block"

Команда "Collection with Universal Data Block" используется для сбора идентификаторов изготовителя радиочастотных меток, серийных номеров радиочастотных меток с содержимым заданных универсальных блоков данных (блоков UDB). Формат команды "Collection with Universal Data Block" показан в таблице 27.


Таблица 27 - Формат команды "Collection with Universal Data Block"

В соответствии с таблицей 27 команда "Collection with Universal Data Block" кроме кода команды должна содержать следующие данные:

- размер окна (Window Size): число интервалов длительностью по 57,3 мс каждый, используемое в алгоритме сбора данных для опроса радиочастотных меток. Описание алгоритма опроса см. в 6.4. Размер окна является целым шестнадцатибитовым числом в диапазоне от 1 до 512;

- максимальная длина пакета (Max Packet Length): целое число (от 20 до 255 включительно), определяющее максимальное значение, которое радиочастотная метка может использовать в ответе в поле длины пакета (Packet Length). Радиочастотная метка может выбрать различную длину пакета ответа, которая не будет превышать значения максимальной длины пакета. Это поле используется для настройки параметров, а также для ограничения времени передачи данных по радиочастотному каналу в соответствии с местными нормами радиорегулирования. Минимальное значение данного параметра равно 20 байтам (15 байт протокольных данных, 1 байт кода типа блока UDB, 2 байта значения общей длины блока UDB и 2 байта значения запрошенного смещения Requested Offset). При этой минимальной длине пакета никаких данных из блока UDB в ответ радиочастотной метки не включается;

- код типа блока UDB (UDB Type Code): указывает тип запрашиваемого блока UDB. Список типов блоков UDB приведен в таблице 40.

Радиочастотная метка должна выбрать случайный временной слот для ответа с учетом переданных ей значений размера окна и максимальной длины пакета (см. 6.4). Метка отвечает на команду "Collection with Universal Data Block" в этом временном слоте. Формат сообщения радиочастотной метки см. в таблице 28.


Таблица 28 - Ответ радиочастотной метки на команду "Collection with Universal Data Block"

Все запрашиваемые командой данные блока UDB радиочастотная метка должна сохранять без изменений с момента получения команды "Collection with Universal Data Block" вплоть до окончания передачи данных в ответном сообщении.

В соответствии с таблицей 28 в своем ответе на команду "Collection with Universal Data Block" радиочастотная метка должна передать код команды и следующую информацию:

- код типа блока UDB: указывает тип запрошенного блока UDB;

- общая длина блока UDB (Total UDB Length): суммарная длина, в байтах, данных блока UDB в радиочастотной метке для заданного типа блока UDB;

- запрошенное смещение (Requested Offset): радиочастотная метка должна представлять значение нуль в своем ответе на команду "Collection with UDB". Все команды "Collection with UDB" должны выполняться с применением смещения нуль, и радиочастотная метка должна отправлять данные, начинающиеся с первого бита запрошенного блока UDB, и подтверждать это значение смещения значением "0" в поле "Запрошенное смещение";

- данные блока UDB: начальная часть данных из универсального блока данных.

6.3.1.1 Универсальный блок данных (блок UDB)

Универсальный блок данных содержит нуль, один или более элементов данных, называемых элементами TLD [Туре (тип), Length (длина), Data (данные)], формат которых показан в таблице 29. Каждый элемент TLD обозначается идентификатором типа элемента UDB (см. таблицу 30). Элементы, которые отсутствуют или длина которых равна нулю, не включаются в блок UDB. Например, если длина пользовательского идентификатора равна нулю, элемент TLD пользовательского идентификатора не должен включаться в блок UDB.


Таблица 29 - Формат элемента TLD

В соответствии с таблицей 29 формат элемента TLD включает следующую информацию:

- идентификатор типа элемента блока UDB: идентифицирует элементы данных, указывает идентификатор типа элемента блока UDB в соответствии с таблицей 30;

- длина: количество байтов элемента данных;

- данные: информационное содержание элемента TLD, например маршрутный код или пользовательский идентификатор.

Значения идентификаторов типов элементов блока UDB представлены в таблице 30.


Таблица 30 - Значения идентификаторов типов элементов блока UDB

Формат элемента "Routing Code" (0x10) показан в таблице 31.


Таблица 31 - Формат элемента "Routing Code" блока UDB

Формат элемента "User ID" (0x11) показан в таблице 32.


Таблица 32 - Формат элемента "User ID" блока UDB

Формат элемента "Optional Command List" (0x12) показан в таблице 33. Данный элемент TLD содержит список однобайтовых значений кодов дополнительных команд, поддерживаемых данной радиочастотной меткой.


Таблица 33 - Формат элемента "Optional Command List" блока UDB

Формат элемента "Memory Size" (0x13) показан в таблице 34. Данные, представляемые в этом элементе TLD, содержат три четырехбайтовых значения: общее число байтов, доступных для команд чтения/записи; общее число байтов в табличной базе данных и текущее доступное число байтов в табличной базе данных (доступный объем памяти не включает область служебных данных и просто показывает число неиспользуемых байтов памяти).


Таблица 34 - Формат элемента "Memory Size" блока UDB

Элемент "Table Query Size" (0x14) должен быть таким, как показано в таблице 35. Восьмибитовое целое положительное число в составе этого элемента TLD представляет число элементов команды "Table Query", поддерживаемое данной радиочастотной меткой.


Таблица 35 - Формат элемента "Table Query Size" блока UDB

Элемент "Table Query Results" (0x15) должен быть таким, как показано в таблице 36. Содержание данного элемента определяется успешным завершением команды "Table Query" и включает в себя значение статуса поиска (Query Status), идентификатор запрошенной таблицы, число совпадений при поиске в данной таблице и порядковый номер первой совпадающей записи.


Таблица 36 - Формат элемента "Table Query Results" блока UDB

Значения поля "Статус поиска" элемента "Table Query Results" показаны в таблице 37.


Таблица 37 - Значения поля "Статус поиска" элемента "Table Query Results"

Элемент "Hardware Fault Status" (0x16) должен быть таким, как показано в таблице 38. Данные, передаваемые в этом элементе TLD, содержат три однобайтовых значения: показания счетчика перезагрузок оборудования; показания счетчика перезагрузок сторожевого таймера (встроенного программного обеспечения самоконтроля) и битовую карту отказов оборудования. Битовая карта отказов оборудования определена в таблице 39.


Таблица 38 - Формат элемента "Hardware Fault Status" блока UDB

Таблица 39 - Битовая карта отказов оборудования

В соответствии с таблицей 39 в битовой карте отказов оборудования указываются следующие биты:

- бит разряда батареи (бит 0): значение "1" показывает "низкий" уровень заряда батареи радиочастотной метки. Точное определение "низкого" уровня устанавливается исходя из применения;

- бит дефекта памяти (бит 1): значение "1" показывает, что радиочастотная метка обнаружила аппаратную неисправность памяти;

- резервные биты (биты 2-7): зарезервированы для использования в будущем.

Тип блока UDB представляет собой заранее определенную совокупность типов элементов блока UDB. Команды "Collection with UDB" и "Read UDB" включают в себя в качестве аргумента тип блока UDB. Это позволяет выбрать одно из заранее определенных сочетаний данных блока UDB. Все типы блока UDB могут включать в себя дополнительные элементы TLD (элементы "Application Extension"), следующие за требуемыми элементами TLD. Значения типов блока UDB должны выбираться в соответствии с таблицей 40.


Таблица 40 - Типы блока UDB

Универсальный блок данных может дополнительно включать в себя один или более элементов "Application Extension", каждый из которых состоит из одного или более элементов TLD, однозначно определенных с помощью идентификаторов применения (см. таблицу 41). Каждая конкретная радиочастотная метка может поддерживать элементы "Application Extension", разработанные различными поставщиками (при наличии соответствующих лицензий).


Таблица 41 - Формат элемента "Application Extension" блока UDB

В соответствии с таблицей 41 элемент "Application Extension" блока UDB содержит следующие поля:

- идентификатор элемента "Application Extension" определен в таблице 30; он указывает на то, что все элементы TLD, включенные в данный блок UDB, определяются идентификатором применения;

- длина элемента "Application Extension": это полная длина элемента "Application Extension" блока UDB в байтах, включая элемент TLD идентификатора применения и длины всех включенных в него элементов TLD применения;

- элемент TLD с идентификатором применения: формат данного элемента TLD определен в таблице 29 и состоит из типа идентификатора применения, однобайтового поля длины и поля данных. Это поле данных содержит значение идентификатора применения для определения указанных далее элементов TLD применения. Типы идентификатора применения определены в таблице 42;

- элементы TLD применения: это последовательность из одного или нескольких элементов TLD, каждый из которых содержит 1 байт идентификатора типа элемента, определяемый указанным идентификатором применения, однобайтовое поле длины и поле данных. Идентификаторы типа элемента TLD определяются исключительно конкретным применением, и не требуется, чтобы они были общедоступными. Формат всех применяемых элементов TLD определен в таблице 29, за исключением тех, идентификатор типа которых присвоен изготовителем не в соответствии с настоящим стандартом. Все элементы TLD должны уложиться в определенную для элемента применения длину в байтах.


Таблица 42 - Типы идентификатора применения

На рисунке 3 показан пример универсального блока данных (блока UDB) типа 0x00. Пример включает в себя элемент маршрутного кода ("Routing Code"), элемент идентификатора пользователя ("User ID") и блок расширения применения с двумя элементами расширения применения ("Application Extension").

Рисунок 3 - Пример универсального блока данных (блока UDB) типа 0x00

Рисунок 3 - Пример универсального блока данных (блока UDB) типа 0x00

6.3.2 Команда "Sleep"

Для перевода радиочастотной метки в спящий режим ей должна быть передана команда, показанная в таблице 43.


Таблица 43 - Формат команды "Sleep" (относится к командам записи)

Получив команду "Sleep", радиочастотная метка переходит в спящее состояние, не выдает на эту команду никакого ответа и не реагирует ни на какие другие команды вплоть до получения сигнала "Wake Up".

6.3.3 Команда "Sleep All But"

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


Таблица 44 - Формат команды "Sleep All But" (относится к командам записи)

Команда "Sleep All But", формат которой показан в таблице 44, должна содержать код команды и следующие данные:

- идентификатор изготовителя радиочастотной метки: идентификатор изготовителя радиочастотной метки, которая должна оставаться в активном состоянии после получения команды "Sleep All But";

- серийный номер радиочастотной метки: серийный номер радиочастотной метки, которая должна оставаться в активном состоянии после получения команды "Sleep All But".

Команда "Sleep All But" является общей. Она используется для перевода всех радиочастотных меток в спящий режим, как команда "Sleep" из 6.3.2, за исключением одной радиочастотной метки, у которой идентификатор изготовителя и серийный номер совпадают с идентификатором изготовителя и серийным номером, указанными в пакете команды. При получении этой команды все радиочастотные метки, за исключением одной, для которой имеет место совпадение переданного идентификатора изготовителя и серийного номера радиочастотной метки, должны перейти в спящее состояние.

Радиочастотные метки на данную команду не отвечают.

6.3.4 Команды защиты информации

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

Рисунок 4 - Схема состояний механизма защиты

Рисунок 4 - Схема состояний механизма защиты

Если защита паролем включена, запись в память радиочастотной метки невозможна, пока она не разблокирована. При этом радиочастотная метка не выполняет требуемые командами операции, а отвечает ошибкой "Authorization Failure".

Если защита паролем выключена, команды выполняются таким образом, как это определено в настоящем стандарте, а ошибка "Authorization Failure" невозможна.

Механизм защиты с помощью пароля включается и выключается по команде "Set Password Protect Mode", описанной в 6.3.4.2.

По умолчанию защита паролем выключена.

При включенной защите паролем радиочастотная метка может быть по команде переведена в разблокированное состояние на некоторое время, в течение которого выполнимы операции записи. Когда радиочастотная метка разблокирована, защищаемые паролем команды записи могут выполняться. По прошествии 30 с с момента получения последней действительной команды или при получении до истечения этого времени команды "Sleep" или "Sleep All But" радиочастотная метка возвращается в заблокированное состояние. При этом защищенные паролем команды невыполнимы. Команда разблокировки "Unlock" переводит радиочастотную метку в разблокированное состояние и описана в 6.3.4.3. Аналогичной команды для перевода радиочастотной метки в заблокированное состояние не существует.

В таблице 45 приведен список команд, выполнение которых зависит от установки защиты паролем.


Таблица 45 - Команды, выполнение которых зависит от установки защиты паролем

6.3.4.1 Команда защиты "Set Password"

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


Таблица 46 - Формат команды записи "Set Password"

В соответствии с таблицей 46 команда записи "Set Password" кроме кода команды должна содержать следующие данные:

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

В ответ на команду "Set Password" радиочастотная метка выдает сообщение частного типа, но без данных (если не обнаружены ошибки), как показано в таблице 47.


Таблица 47 - Формат ответа на команду "Set Password"

Команда "Set Password" устанавливает пароль для радиочастотной метки. Перед установкой пароля требуется сначала выдать радиочастотной метке команду "Unlock" (см. 6.3.4.3), чтобы команда "Set Password" могла быть выполнена. Начальное значение пароля всех радиочастотных меток равно "0xFFFFFFFF". Возможные ответы с кодами ошибок показаны в таблице 48.


Таблица 48 - Ошибки при выполнении команды "Set Password"

6.3.4.2 Команда защиты "Set Password Protect Mode"

Для перевода радиочастотной метки в режим защиты с помощью пароля метке должна быть направлена команда "Set Password Protect Mode" (команда записи), представленная в таблице 49.


Таблица 49 - Формат команды записи "Set Password Protect Mode"

В соответствии с таблицей 49 команда записи "Set Password Protect Mode" кроме кода команды должна содержать следующие данные:

- флаг защиты: определяет, включен или выключен режим защиты с помощью пароля. Значение флага "0x01" означает, что режим защиты включен, значение "0x00" - выключен.

На команду "Set Password Protect Mode" радиочастотная метка отвечает сообщением частного типа, но без данных (если не обнаружены ошибки), как показано в таблице 50.


Таблица 50 - Формат ответа на команду записи "Set Password Protect Mode"

Эта команда включает или выключает защиту паролем метки. Для выполнения данной команды метка должна быть сначала разблокирована с помощью команды "Unlock" (см. 6.3.4.3), независимо от состояния режима защиты паролем. Возможные коды ошибки в ответе метки показаны в таблице 51.


Таблица 51 - Ошибки при выполнении команды "Set Password Protect Mode"

6.3.4.3 Команда защиты "Unlock"

Для разблокировки радиочастотной метки ей посылается команда (для записи), формат которой показан в таблице 52.


Таблица 52 - Формат команды записи "Unlock"

В соответствии с таблицей 52 команда "Unlock" кроме кода команды должна содержать следующие данные:

- пароль: четыре байта в двоичном коде, которые предварительно устанавливаются как пароль с помощью команды "Set Password".

В ответ на команду "Unlock" радиочастотная метка выдает сообщение, формат которого показан в таблице 53.


Таблица 53 - Формат ответа на команду записи "Unlock"

Данная команда осуществляет разблокировку радиочастотной метки. Если указанный в команде пароль совпадает с паролем радиочастотной метки, она должна выполнять все команды, обычно недоступные при включенной защите паролем. Метка остается в разблокированном состоянии вплоть до получения команды "Sleep" или "Sleep All But" или в течение 30 с после получения последней команды. Возможные коды ошибки в ответе радиочастотной метки показаны в таблице 54.


Таблица 54 - Ошибки при выполнении команды "Unlock"

6.3.5 Команды передачи информации

6.3.5.1 Команда "User ID"

Для чтения значения пользовательского идентификатора используется команда "User ID", формат которой показан в таблице 55.


Таблица 55 - Формат команды чтения "User ID"

Получившая команду чтения "User ID" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 56.


Таблица 56 - Формат ответа на команду чтения "User ID"

В соответствии с таблицей 56 в своем ответе на команду чтения "User ID" радиочастотная метка должна передать код команды и следующую информацию:

- длина пользовательского идентификатора: число байтов пользовательского идентификатора, при этом имеет значение от 0 до 60 байтов включительно;

- значение пользовательского идентификатора: содержание пользовательского идентификатора в радиочастотной метке.

Для записи в радиочастотную метку пользовательского идентификатора используется команда "User ID", формат которой показан в таблице 57.


Таблица 57 - Формат команды записи "User ID"

В соответствии с таблицей 57 команда записи "User ID" должна содержать код команды и следующую информацию:

- длина пользовательского идентификатора: число байтов идентификатора, при этом N имеет значение от 0 до 60 байтов включительно;

- значение пользовательского идентификатора: содержание пользовательского идентификатора.

Получившая команду записи "User ID" радиочастотная метка должна ответить сообщением частного типа, показанным в таблице 58. Никаких данных не передается, если не обнаружены ошибки при выполнении команды.


Таблица 58 - Формат ответа на команду записи "User ID"

Пользовательский идентификатор располагается в доступной для чтения и записи пользовательской памяти радиочастотной метки размером до 60 байт, значение и размер которой определяются пользователем. Формат и содержание пользовательского идентификатора должны удовлетворять требованиям к уникальным идентификаторам по ИСО/МЭК 15459-1. Кроме того, организации, намеренные присваивать уникальный пользовательский идентификатор, должны руководствоваться правилами, установленными аккредитованными агентствами выдачи таких идентификаторов. В соответствии с ИСО/МЭК 15459-2 агентства выдачи должны обращаться за регистрацией в Нидерландский институт по стандартизации (Орган регистрации по ИСО/МЭК 15459):

"NEN" ("Netherlands Normalisatie-instituut")

Адрес:

Postbus 5059,

2600 GB Delft,

The Netherlands

Факс: +31 15 26 90 242

E-mail: [email protected]

Команда "User ID" устанавливает и считывает размер и содержание пользовательского идентификатора. Кроме данной команды, чтение пользовательского идентификатора можно осуществить с помощью команд "Collection With UDB" и "Read Universal Data Block", за исключением случая, когда параметр длины пользовательского идентификатора равен нулю. В этом случае сообщение с блоком UDB не будет содержать пользовательского идентификатора. По умолчанию длина пользовательского идентификатора равна нулю.

Возможные коды ошибки в ответе радиочастотной метки на команду "User ID" показаны в таблице 59.


Таблица 59 - Ошибки при выполнении команды "User ID"

6.3.5.2 Команда "Routing Code"

Для чтения значения маршрутного кода используется команда "Routing Code", формат которой показан в таблице 60.


Таблица 60 - Формат команды чтения "Routing Code"

Получившая команду чтения "Routing Code" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 61.


Таблица 61 - Формат ответа на команду чтения "Routing Code"

В соответствии с таблицей 61 в своем ответе на команду чтения "Routing Code" радиочастотная метка должна передать код команды и следующую информацию:

- длина маршрутного кода: число байтов в считываемом маршрутном коде, при этом N имеет значение от 0 до 50 байтов включительно;

- значение маршрутного кода: содержание маршрутного кода, записанного в памяти радиочастотной метки.

Для записи в память радиочастотной метки маршрутного кода используется команда "Routing Code", формат которой показан в таблице 62.


Таблица 62 - Формат команды записи "Routing Code"

В соответствии с таблицей 62 команда записи "Routing Code" должна содержать код команды и следующую информацию:

- длина маршрутного кода: число байтов в записываемом маршрутном коде, при этом N имеет значение от 0 до 50 байтов включительно;

- значение маршрутного кода: данные, записываемые в поле маршрутного кода в память радиочастотной метки.

Получившая команду записи "Routing Code" радиочастотная метка должна ответить сообщением частного типа, показанным в таблице 63. Никаких данных не передается, если не обнаружены ошибки при выполнении команды.


Таблица 63 - Формат ответа на команду записи "Routing Code"

Маршрутный код располагается в доступной для чтения и записи пользователем области памяти радиочастотной метки, назначение и размер которой (до 50 байтов) определяет сам пользователь. Маршрутный код должен использоваться в соответствии с требованиями ИСО 17363. Следует иметь в виду, что маршрутный код является частью ответа радиочастотной метки на команды "Collection With UDB" и "Read Universal Data Block", за исключением случая, когда параметр длины маршрутного кода установлен на нуль, в этом случае сообщение с блоком UDB не будет содержать маршрутного кода. Длина маршрутного кода по умолчанию равна нулю.

Возможные коды ошибки в ответе радиочастотной метки на команду "Routing Code" показаны в таблице 64.


Таблица 64 - Ошибки при выполнении команды "Routing Code"

6.3.6 Команды чтения неизменной информации, заданной изготовителем

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

6.3.6.1 Команда "Firmware Version"

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


Таблица 65 - Формат команды чтения "Firmware Version"

Получившая команду чтения "Firmware Version" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 66.


Таблица 66 - Формат ответа на команду "Firmware Version"

В соответствии с таблицей 66 в своем ответе на команду "Firmware Version" радиочастотная метка должна передать код команды и следующую информацию:

- версия МПО радиочастотной метки: определяемое изготовителем неизменное значение номера версии МПО. В этом поле радиочастотная метка указывает версию своего МПО.

6.3.6.2 Команда "Model Number"

Для чтения номера модели радиочастотной метки используется команда, формат которой показан в таблице 67.


Таблица 67 - Формат команды чтения "Model Number"

Получившая команду "Model Number" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 68.


Таблица 68 - Формат ответа на команду "Model Number"

В соответствии с таблицей 67 в своем ответе на команду "Model Number" радиочастотная метка должна передать код команды и следующую информацию:

- номер модели радиочастотной метки: определяемое изготовителем и неизменное для данной радиочастотной метки значение. В этом поле радиочастотная метка указывает номер своей модели.

6.3.7 Команды обращения к памяти радиочастотной метки

Радиочастотная метка может обеспечивать запись и хранение одного или более байтов данных в доступной пользователю области памяти произвольного доступа, в которой пользователь может хранить и считывать определяемые пользователем данные. Эта память независима от других форматов хранения информации (таких как пользовательский идентификатор или табличные базы данных), определенных в настоящем стандарте. Каждому байту данных в области памяти соответствует адрес в виде целого числа без знака, посредством которого к каждому байту памяти может быть осуществлен доступ. Число байтов данных (число В) в памяти метки однозначно определяется адресами от "0" до "В - 1".

6.3.7.1 Команда "Write Memory"

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


Таблица 69 - Формат команды записи "Write Memory"

Команда "Write Memory", формат которой показан в таблице 69, должна содержать код команды и следующие данные:

- число байтов данных: число N, число записываемых байтов, в диапазоне от 1 до 237 байт включительно. Число байтов данных в пакете команды "Write Memory" не должно превышать 237 байтов (то есть 255-18=237, где 18 - это суммарная длина части пакета команды, состоящего из заголовка, поля числа байтов данных, поля начального адреса и кода CRC);

- начальный адрес: значение адреса памяти для первого записываемого байта в диапазоне от "0" до максимального значения адреса, определенного изготовителем радиочастотной метки;

- данные: содержание записываемой информации.

Получившая команду записи "Write Memory" радиочастотная метка должна ответить сообщением частного типа, показанным в таблице 70. Никаких данных не передается, если не обнаружены ошибки при выполнении команды.


Таблица 70 - Формат ответа на команду записи "Write Memory"

После выполнения команды "Write Memory" радиочастотная метка хранит данные в доступной пользователю области памяти со свободным доступом. Эти данные в дальнейшем могут быть считаны с помощью команды "Read Memory".

Возможные коды ошибки в ответе метки на команду "Write Memory" показаны в таблице 71.


Таблица 71 - Ошибки при выполнении команды "Write Memory"

6.3.7.2 Команда "Read Memory"

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


Таблица 72 - Формат команды чтения "Read Memory"

В соответствии с таблицей 72 команда "Read Memory" должна содержать код команды и следующие данные:

- число считываемых байтов: число байтов для чтения в диапазоне от 1 до 239 байт включительно. Число байтов данных в пакете команды "Read Memory" не должно превышать 239 байт (то есть 255-16=239, где 16 - это суммарная длина части пакета команды, состоящего из заголовка, поля числа байтов и кода CRC);

- начальный адрес: значение адреса памяти для первого считываемого байта в диапазоне от "0" до максимального значения адреса, определенного изготовителем радиочастотной метки.

Получившая команду "Read Memory" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 73.


Таблица 73 - Формат ответа на команду чтения "Read Memory"

В соответствии с таблицей 73 в своем ответе на команду чтения "Read Memory" радиочастотная метка должна передать код команды и следующую информацию:

- число реально считанных байтов: число N байтов данных в ответе, которое должно совпадать с параметром числа считываемых байтов в команде;

- данные: содержание считанной области памяти метки.

Считанные данные предварительно записываются в память радиочастотной метки с помощью команды "Write Memory".

Возможные коды ошибки в ответе метки на команду "Read Memory" показаны в таблице 74.


Таблица 74 - Ошибки при выполнении команды "Read Memory"

6.3.8 Команда "Delete Writeable Data"

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


Таблица 75 - Формат команды "Delete Writeable Data"

Получившая команду записи "Delete Writeable Data" радиочастотная метка должна ответить сообщением частного типа, показанным в таблице 76. Никаких данных не передается, если не обнаружены ошибки при выполнении команды.


Таблица 76 - Формат ответа на команду записи "Delete Writeable Data"

Данная команда возвращает всю доступную пользователю память к заводским настройкам. При этом выполняются следующие операции:

- значение длины идентификатора изготовителя устанавливается равным нулю;

- значение длины маршрутного кода устанавливается равным нулю;

- все табличные базы данных удаляются (определение баз данных см. в 6.3.10);

- для пароля устанавливается начальное значение "0xFFFFFFFF";

- выключается режим защиты паролем;

- все маркеры баз данных становятся недействительными;

- таблица "Table Query Results" (идентификатор таблицы - "0x0000") очищается.

Возможные коды ошибки в ответе метки на команду "Delete Writeable Data" показаны в таблице 77.


Таблица 77 - Ошибки при выполнении команды "Delete Writeable Data"

6.3.9 Команда "Read Universal Data Block"

Команда "Read Universal Data Block" используется для считывания универсального блока данных (блока UDB). Как указано в 6.3.1.1, размер блока UDB может быть настолько большим, что для его считывания используются несколько последовательных команд "Read Universal Data Block". Смещение в поле блока UDB позволяет УСО запросить определенную часть из полного блока UDB. Для считывания универсального блока данных радиочастотной метке должна быть направлена команда "Read Universal Data Block". Формат команды показан в таблице 78.


Таблица 78 - Формат команды "Read Universal Data Block"

В соответствии с таблицей 78 команда "Read Universal Data Block" кроме кода команды должна содержать следующие данные:

- код типа блока UDB: идентифицирует тип запрошенного блока UDB. См. 6.3.1.1, где полнее раскрыто поле типа блока UDB;

- смещение в блоке UDB (Offset into UDB): параметр, используемый УСО для определения начального смещения адреса данных в требуемом блоке UDB. Чтобы считать длинный блок UDB, УСО использует серию команд "Read Universal Data Block" и увеличивает значение смещения после каждого успешно принятого ответа радиочастотной метки;

- максимальная длина пакета: целое число в диапазоне от 21 до 255 включительно, которое определяет максимальную длину пакета данных в ответе радиочастотной метки. Значение "21" включает 15 байт "упаковки" пакета, 1 байт кода типа блока UDB, 2 байта значения общей длины блока UDB, 2 байта значения требуемого смещения и, как минимум, 1 байт данных блока UDB.

Получившая команду чтения "Read Universal Data Block" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 79.


Таблица 79 - Формат ответа на команду "Read Universal Data Block"

В соответствии с таблицей 79 в своем ответе на команду "Read Universal Data Block" радиочастотная метка должна передать код команды и следующую информацию:

- код типа блока UDB: тип запрошенного блока UDB;

- общая длина блока UDB: полная длина данных блока UDB, в байтах, радиочастотной метки для выбранного типа блока UDB;

- запрошенное смещение: значение, представленное в пакете команды УСО;

- универсальный блок данных: часть универсального блока данных. Содержание и формат универсального блока данных описаны в 6.3.1.

Чтобы считать весь блок UDB, УСО начинает с команды со значением смещения "0" в блоке UDB и максимальной длиной пакета, установленной на наибольшее допустимое значение. Радиочастотная метка может сама выбрать меньший размер пакета, чем заданный в максимальной длине пакета, но не может превысить его. После успешного получения начальной части блока UDB УСО может увеличить значение смещения в блоке UDB до начала несчитанной порции байт и выдать повторную команду "Read Universal Data Block". Таким образом УСО может продолжать чтение, но при этом оно не должно считывать обязательно весь блок UDB. Кроме того, УСО не должно обязательно придерживаться определенного порядка изменения значения смещения в блоке UDB при подаче радиочастотной метке последовательных команд чтения.

Возможные коды ошибки в ответе радиочастотной метки на команду "Read Universal Data Block" показаны в таблице 80.


Таблица 80 - Ошибки при выполнении команды "Read Universal Data Block"

6.3.10 Команды табличных баз данных

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

Вид таблицы определяется списком полей (столбцов), ширина которых измеряется в байтах. Поля имеют последовательную нумерацию слева направо, начиная с "0" для первого поля. Все поля в таблице однотипны в том смысле, что сравнение их значений производится последовательно по байтам, а равными считаются значения полей, в которых все байты данных совпадают. Значение одного поля считается меньше значения второго, если все байты с номерами от "0" до "1" совпадают, а байт с номером "" в первом поле меньше байта с этим номером во втором. Иными словами, в строке сравнения первый байт является старшим, а последний байт - младшим.

Табличные записи (строки) также нумеруются, начиная с "0" для первой записи. Порядковый номер записи не привязан к записи жестко. При удалении записи все остальные перенумеровываются, и их порядковые номера могут отличаться от присвоенных ранее (до команды удаления "Table Delete Record").

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

По значению идентификаторов таблицы делятся на несколько типов, определенных в таблице 81.


Таблица 81 - Определение полей значений идентификаторов таблицы

Значения идентификаторов таблиц в диапазоне "определен ИСО" зарезервированы для использования в будущих версиях настоящего стандарта. Значение идентификатора таблицы "0x0000" зарезервировано для таблицы результатов поиска "Query Results Table" (см. 6.3.10.10).

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

Значения идентификаторов таблиц в диапазоне "изготовителя/продавца" зарезервированы для реализации продавцом дополнительных функций и расширений в процессе изготовления и сбыта. В этой области значений чтение и запись таблиц базы данных должно производиться с помощью стандартных команд для базы данных, но таблицы могут иметь дополнительные свойства и функции. Значения идентификаторов таблиц в диапазоне "изготовителя/продавца" доступны для использования исключительно по усмотрению изготовителя/продавца, отсутствуют требования публикации назначения или используемого интерфейса внутри этой области идентификаторов таблиц. Данные, собираемые с помощью команды "Collection with UDB", содержат данные из блока данных изготовителя (блока MDB) и из универсального блока данных (блока UDB). Данные блока MDB должны храниться в таблицах базы данных со значениями идентификаторов таблиц из диапазона "изготовителя/продавца", как описано в 6.3.10.
_______________
Данное предложение записано вместо предложения "Данные, собираемые с помощью команды "Collect with UDB", содержат данные из блока данных изготовителя (Manufacturers Data Block - MDB) и из универсального блока данных Universal Data Block (UDB)" по ИСО/МЭК 18000-7.


Маркеры чтения и записи

Некоторые команды чтения и записи таблиц связаны с элементами данных, называемыми маркерами (Token). Маркеры дают возможность последовательного доступа к данным, размер которых превосходит возможности передачи в одном сообщении метки, а также применяются для обнаружения и исправления ошибок. Команды записи ("Table Add Records", "Table Update Record" и "Table Update Fields") описывают начальное состояние логических переменных (идентификатора таблицы, номера записи, номера поля) и итог выполнения команды. Команда чтения "Table Get Data" описывает только начальное состояние. При получении одной из этих команд радиочастотная метка генерирует значение маркера и возвращает его УСО. Соответственно маркеры входят в состав команд "Table Read Fragment" или "Table Write Fragment" и возвращаются к той же радиочастотной метке вместе с любыми необходимыми данными (подвергаемыми контекстно-зависимому ограничению объема). Радиочастотная метка производит чтение или запись, также подвергаемые контекстно-зависимому ограничению объема, и генерирует новое значение маркера. Новый маркер передается назад в УСО и используется в последующих командах "Table Read Fragment" или "Table Write Fragment".

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

а) когда УСО посылает серию команд "Table Read Fragment" или "Table Write Fragment", радиочастотная метка по значению маркера должна отличать каждую следующую команду в серии от предыдущей. Например, если УСО отправило радиочастотной метке команду чтения или записи фрагмента, не получило от нее ответа и повторило команду снова, радиочастотная метка должна определить эту команду с помощью маркера как повторную попытку. См. ниже раздел о ситуациях с повторными операциями с базами данных;

b) в ответе на последнюю команду серии команд с учетом ограничений, наложенных командами "Table Add Records", "Table Update Records", "Table Update Records Fields" или командой "Table Get Data" предшествующей серии, радиочастотная метка должна вернуть однобайтовый маркер со специальным значением "0x00". Специальное значение информирует УСО, что радиочастотная метка считает, что серия команд завершена;

c) радиочастотная метка должна поддерживать существование множества независимых маркеров чтения и может поддерживать существование множества независимых маркеров записи. Радиочастотная метка должна поддерживать, как минимум, два независимых маркера чтения.

Маркер чтения генерируется при получении команды "Table Get Data" и используется в последовательности команд "Table Read Fragment". Маркер записи генерируется при получении команд записи таблиц и используется в последовательности команд "Table Write Fragment". Командами записи в таблицы являются "Table Add Records", "Table Update Records" и "Table Update Records Fields". Поддержка нескольких независимых маркеров чтения означает, что процедуры, связанные с командами "Table Get Data" или "Table Read Fragment", использующими разные маркеры, не связаны друг с другом, даже если два маркера связаны с одной и той же таблицей. Поддержка множества независимых маркеров записи означает, что выполнение команды записи таблицы ("Table Add Records", "Table Update Records" и "Table Update Fields") с одним маркером не будет влиять на операции любой другой команды записи таблицы с другим маркером при условии, что два маркера связаны с разными таблицами. Подача любой команды записи в таблицу приводит к отмене значений всех ранее установленных для этой таблицы маркеров чтения и записи.

Старшие четыре бита первого байта маркера указывают его длину без первого байта, т.е. их нулевое значение соответствует длине маркера в 1 байт (см. команду "Table Write Fragment"). Полностью нулевое значение маркера "0x00" зарезервировано как указатель условия конца итераций. Структура поля маркера показана ниже в таблице 82.


Таблица 82 - Структура маркера

Команды работы с таблицами делятся на команды чтения и записи. К командам чтения относятся команды "Table Get Data", "Table Get Properties", "Table Query" и "Table Read Fragment"; команды записи включают в себя команды "Table Create", "Table Add Records", "Table Update Records", "Table Update Fields", "Table Delete Record" и "Table Write Fragment". Для всех команд записи таблиц требуется организация повторной записи данных в метку при любой ошибке первичной команды записи.

Особые ситуации - повторные операции с базами данных

Для команд "Table Create", "Table Add Records", "Table Delete Records", "Table Read Fragment" и "Table Write Fragment" необходим определенный порядок действий по обработке ошибок на тот случай, если УСО не был получен ответ об успешном выполнении команды, и поэтому требуется повторить команду. Повторный пакет команды должен полностью копировать первичный, используя точно те же значения идентификатора сеанса, кода команды, субкода команды, идентификатора последовательности или маркера запроса, идентификатора таблицы (если используется) и данных (если они используются). Радиочастотная метка должна определить, является ли запрос повтором предшествовавшей команды путем сравнения с ранее полученным пакетом команды. Если радиочастотная метка определяет, что запрос является повтором ранее выполненной и успешной команды по работе с базой данных, то она должна повторно отправить тот же ответ, что и на успешно выполненную предыдущую команду. Подробности см. в описаниях команд "Table Add Records", "Table Delete Records", "Table Read Fragment" и "Table Write Fragment". Следует иметь в виду, что прочие команды обращения к базе данных также могут требовать повторения, и эти повторные обращения должны поддерживаться.

6.3.10.1 Команда "Table Create"

Для создания таблицы радиочастотной метке передается команда "Table Create", показанная в таблице 83.


Таблица 83 - Формат команды "Table Create"

В соответствии с таблицей 83 команда "Table Create" должна содержать код команды и следующие данные:

- идентификатор таблицы: идентификатор, присвоенный таблице. Действующая область значений идентификатора от "0x0001" до "0xFFFF". Идентификатор таблицы "0x0000" зарезервирован для таблицы "Query Results Table";

- максимальное число записей (Maximum Number of Records): определяет конечное число записей, которое может существовать в таблице. Действительное значение - от "0x0001" до "0xFFFF". Дополнительным ограничением числа записей может быть незадействованная емкость табличной памяти радиочастотной метки;

- число полей (Number of Fields): число полей , приходящихся на запись. Действительное значение находится в диапазоне от 1 до 32;

- длина каждого поля (Length of Each Field): байтовый массив со значениями длин в байтах для полей. Каждый однобайтовый элемент массива байтов означает размер поля. Первый элемент массива байтов определяет длину первого поля с номером "0", второй элемент определяет длину второго поля с номером "1" и т.д. Длина поля должна быть в диапазоне значений от 1 до 255 включительно.

Получившая команду "Table Create" радиочастотная метка должна ответить сообщением частного типа, показанным в таблице 84. Никаких данных не передается, если не обнаружены ошибки при выполнении команды.


Таблица 84 - Формат ответа на команду "Table Create"

Команда создает таблицу для базы данных с определенным максимальным числом записей. Формат таблицы определяется заданным числом полей с определенной для каждого из них длиной данных. Созданная по команде таблица изначально не имеет записей.

Возможные коды ошибки в ответе радиочастотной метки на команду "Table Create" показаны в таблице 85.

Примечание - Если радиочастотная метка идентифицирует данную команду как повторение успешно выполненной предыдущей, она не выполняет команду вновь, а просто повторно посылает переданный ранее ответ.


Таблица 85 - Ошибки при выполнении команды "Table Create"

6.3.10.2 Команда "Table Add Records"

Для подготовки к выполнению записей в таблицу радиочастотной метке передается команда "Table Add Records", показанная в таблице 86.


Таблица 86 - Формат команды "Table Add Records"

В соответствии с таблицей 86 команда "Table Add Records" должна содержать код команды и следующие данные:

- идентификатор таблицы: идентификатор, присвоенный таблице;

- идентификатор последовательности (Sequence ID): используется для определения уникальных транзакций. При каждой выдаче данной команды УСО сообщает различные значения идентификатора последовательности. Если УСО не получает ответа (например, из-за нарушения связи), оно должно повторить команду "Table Add Record" с тем же значением идентификатора последовательности, что и в неудавшейся попытке. Радиочастотная метка проверяет, отличается ли значение идентификатора последовательности от полученного с последней успешно выполненной командой "Table Add Record" и, если отличается, то добавляет записи в таблицу;

- количество записей (Number of Records): показывает общее число записей, которое нужно добавить в таблицу. Допустимое значение - от "1" до максимального числа записей, определенного при создании таблицы (см. 6.3.10.1), за вычетом уже добавленного в таблицу количества записей.

Получившая команду "Table Add Records" радиочастотная метка должна ответить сообщением, формат которого показан в таблице 87.


Таблица 87 - Формат ответа на команду "Table Add Records"

В соответствии с таблицей 87 в своем ответе на команду "Table Add Records" радиочастотная метка должна передать код команды и следующую информацию:

- маркер (Token): указывает значение, используемое далее для итерационного процесса добавления записей. Значение "0x00" зарезервировано для обозначения конца итерационного процесса. Структура поля маркера показана в таблице 82.

Команда "Table Add Records" передает радиочастотной метке указание подготовиться к выполнению определенного количества записей в таблице. Содержание записей заносится в таблицу с помощью последовательности команд "Table Write Fragment". Эта команда делает недействительными любые существующие маркеры для данного идентификатора таблицы. Эта команда также делает недействительными результаты команды "Table Query Results", находящиеся в таблице с идентификатором "0x0000".

Примечание - Если радиочастотная метка идентифицирует данную команду как повторение успешно выполненной, она не выполняет команду вновь, а повторно посылает переданный ранее ответ.


Возможные коды ошибки в ответе радиочастотной метки на команду "Table Add Records" показаны в таблице 88.


Таблица 88 - Ошибки при выполнении команды "Table Add Records"

6.3.10.3 Команда "Table Update Records"

Для подготовки к изменению записей в таблице радиочастотной метке передается команда "Table Update Records", показанная в таблице 89.


Таблица 89 - Формат команды "Table Update Records"

В соответствии с таблицей 89 команда "Table Update Records" должна содержать код и субкод команды и следующие данные:

- идентификатор таблицы: идентификатор, присвоенный таблице;

- номер начальной записи (Starting Record Number): указывает на первую из записей, содержание которой подлежит изменению. Действительное значение - от "0" до числа записей в таблице за вычетом единицы;

- число записей (Number of Records): показывает общее число записей, которое нужно изменить в таблице. Действительное значение - от "1" до числа записей в таблице за вычетом номера начальной записи.

Получившая команду "Table Update Records" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 90.


Таблица 90 - Формат ответа на команду "Table Update Records"

В соответствии с таблицей 90 в своем ответе на команду "Table Update Records" радиочастотная метка должна передать код команды и следующую информацию:

- маркер: указывает значение, используемое для итерационной записи данных в обновляемых записях. Значение маркера "0x00" зарезервировано для обозначения конца итерационного процесса. Структура поля маркера показана в таблице 82.

Команда "Table Update Records" передает радиочастотной метке указание подготовиться к изменению определенного количества записей в таблице. Содержание записей заносится в таблицу с помощью последовательности команд "Table Write Fragment". Эта команда делает недействительными существующие маркеры для этого идентификатора таблицы. Эта команда также делает недействительными любые результаты команды "Table Query", представленные в таблице с идентификатором "0x0000".

Возможные коды ошибки в ответе радиочастотной метки на команду "Table Update Records" показаны в таблице 91.


Таблица 91 - Ошибки при выполнении команды "Table Update Records"

6.3.10.4 Команда "Table Update Fields"

Для подготовки к обновлению полей в таблице радиочастотной метке передается команда "Table Update Fields", показанная в таблице 92.


Таблица 92 - Формат команды "Table Update Fields"

В соответствии с таблицей 92 команда "Table Update Fields" должна содержать код и субкод команды, а также следующие данные:

- идентификатор таблицы: идентификатор, присвоенный таблице;

- номер записи (Record Number): определяет обновляемую запись. Действительное значение - от "0" до числа полей в таблице за вычетом единицы;

- номер начального поля (Starting Field Number): указывает первое поле записи, содержание которого подлежит изменению. Действительное значение - от "0" до числа полей в таблице за вычетом единицы;

- число полей (Number of Fields): показывает общее число полей в определенной записи, содержание которых нужно обновить. Действительное значение - от "1" до числа полей в таблице за вычетом номера начального поля.

Команда "Table Update Fields" передает радиочастотной метке указание подготовиться к обновлению определенного числа полей в таблице. Новое содержание полей заносится в таблицу с помощью последовательности команд "Table Write Fragment". Эта команда может только изменять поля в одной записи, номер записи которой указан в команде. Эта команда делает недействительным любой существующий маркер для данного идентификатора таблицы. Эти команды также делают недействительным любые результаты команды "Table Query", находящиеся в таблице с идентификатором "0x0000".

Получившая команду "Table Update Fields" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 93.


Таблица 93 - Формат ответа на команду "Table Update Fields"

В соответствии с таблицей 93 в своем ответе на команду "Table Update Fields" радиочастотная метка должна передать код команды и следующую информацию:

- маркер: значение, используемое для итерационной записи данных в обновляемые записи. Значение маркера "0x00" зарезервировано для обозначения конца итерационного процесса. Структура поля маркера показана в таблице 82.

Возможные коды ошибки в ответе радиочастотной метки на команду "Table Update Fields" показаны в таблице 94.


Таблица 94 - Ошибки при выполнении команды "Table Update Fields"

6.3.10.5 Команда "Table Delete Record"

Для удаления записи из существующей таблицы радиочастотной метке передается команда "Table Delete Record", показанная в таблице 95.


Таблица 95 - Формат команды "Table Delete Record"

В соответствии с таблицей 95 команда "Table Delete Record" должна содержать код и субкод команды, а также следующие данные:

- идентификатор таблицы: идентификатор, присвоенный таблице;

- идентификатор последовательности: используется для определения уникальной транзакции. При каждой выдаче данной команды УСО сообщает различные значения идентификатора последовательности. Если УСО не получает ответа на команду (например, из-за нарушения связи), оно должно повторить команду "Table Delete Record" с тем же значением идентификатора последовательности, что и в неудавшейся попытке. Радиочастотная метка проверяет, отличается ли значение идентификатора от полученного с последней успешно выполненной командой "Table Delete Record" и, если отличается, то удаляет запись из таблицы;

- номер записи: порядковый номер удаляемой записи.

Получившая команду "Table Delete Record" радиочастотная метка должна ответить сообщением частного типа, показанным в таблице 96. Никаких данных не передается, если не обнаружены ошибки при выполнении команды.


Таблица 96 - Формат ответа на команду "Table Delete Record"

Команда "Table Delete Record" передает радиочастотной метке указание удалить одну запись из таблицы. Оставшиеся записи перенумеровываются таким образом, чтобы сохранить последовательность нумерации и чтобы номер первой записи был всегда равен "0x0000". При выполнении команды "Table Delete Record" порядок остающихся записей в таблице является произвольным и может отличаться от порядка записей, предшествовавших команде "Table Delete Record".

Эта команда делает недействительными любые существующие маркеры для этого идентификатора таблицы. Чтобы считать данные из базы данных или записать их в нее, необходимо подать новую команду записи ("Table Add Records", "Table Update Records", "Table Update Fields") или чтения ("Table Get Data").

Эта команда также делает недействительными результаты команды "Query Results", представленные в таблице с идентификатором "0x0000".

Возможные коды ошибки в ответе метки на команду "Table Delete Record" показаны в таблице 97.


Таблица 97 - Ошибки при выполнении команды "Table Delete Record"

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

6.3.10.6 Команда "Table Get Data"

Для подготовки к чтению данных из таблицы радиочастотной метке передается команда "Table Get Data", показанная в таблице 98.


Таблица 98 - Формат команды "Table Get Data"

В соответствии с таблицей 98 команда "Table Get Data" должна содержать код и субкод команды, а также следующие данные:

- идентификатор таблицы: определяет идентификатор, присвоенный таблице;

- номер начальной записи: определяет первую запись, с которой начнется чтение данных;

- номер начального поля: определяет первое поле, с которого начнется чтение данных.

Получившая команду "Table Get Data" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 99.


Таблица 99 - Формат ответа на команду "Table Get Data"

В соответствии с таблицей 99 в своем ответе на команду "Table Get Data" радиочастотная метка должна передать код команды и следующую информацию:

- маркер: указывает значение, используемое для итерационного чтения данных. Значение маркера "0x00" зарезервировано для обозначения конца итерационного процесса. Структура поля маркера показана в таблице 82.

Команда "Table Get Data" передает радиочастотной метке указание подготовить для чтения данные из таблицы, начиная с указанных номеров записи и поля. Непосредственно чтение данных производится с помощью последовательности команд "Table Read Fragment". В отличие от команд записи в таблицу ("Table Add Records", "Table Update Records", "Table Update Fields") команда "Table Get Data" имеет итерационно открытое окончание, т.е. может ограничиваться как пределами таблицы, так и применяемыми программными средствами.

Маркеры, полученные по команде "Table Get Data" и возвращаемые радиочастотной метке с командами "Table Read Fragment", отменяются следующими командами, обращенными к таблице с тем же идентификатором: "Delete Writeable Data", "Table Add Records", "Table Update Records", "Table Update Fields", "Table Delete Record" и "Table Write Fragment".

Возможные коды ошибки в ответе радиочастотной метки на команду "Table Get Data" показаны в таблице 100.


Таблица 100 - Ошибки при выполнении команды "Table Get Data"

6.3.10.7 Команда "Table Get Properties"

Для получения данных о формате таблицы радиочастотной метке передается команда "Table Get Properties", показанная в таблице 101.


Таблица 101 - Формат команды "Table Get Properties"

В соответствии с таблицей 101 команда "Table Get Properties" должна содержать код и субкод команды, а также следующие данные:

- идентификатор таблицы: идентификатор, присвоенный таблице.

По команде "Table Get Properties" радиочастотная метка передает информацию об определенной таблице в сообщении, формат которого показан в таблице 102.


Таблица 102 - Формат ответа на команду "Table Get Properties"

В соответствии с таблицей 102 в своем ответе на команду "Table Get Properties" радиочастотная метка должна передать код команды и следующую информацию:

- общее число записей: общее число записей в таблице;

- максимальное число записей: максимальное число записей, установленных для таблицы командой "Table Create" при создании таблицы;

- зарезервировано: 1 байт со значением "0x00", зарезервированный для использования в будущем.

Возможные коды ошибки в ответе радиочастотной метки на команду "Table Get Properties" показаны в таблице 103.


Таблица 103 - Ошибки при выполнении команды "Table Get Properties"

6.3.10.8 Команда "Table Read Fragment"

Для считывания фрагмента данных из таблицы радиочастотной метке передается команда "Table Read Fragment", показанная в таблице 104.


Таблица 104 - Формат команды "Table Read Fragment"

В соответствии с таблицей 104 команда "Table Read Fragment" должна содержать код и субкод команды, а также следующие данные:

- маркер запроса (Request Token): маркер, полученный в ответ на предыдущую команду "Table Get Data" или "Table Read Fragment". Значение маркера "0x00" зарезервировано для указания конца итерационного процесса. Структура поля маркера показана в таблице 82;

- длина данных запроса (Requested Read Length): длина строки данных, которая должна быть передана в ответе радиочастотной метки. Действительное значение - от 1 до 46 байтов.

Получившая команду "Table Read Fragment" радиочастотная метка должна ответить сообщением частного типа с кодом команды и данными, показанными в таблице 105.


Таблица 105 - Формат ответа на команду "Table Read Fragment"

В соответствии с таблицей 105 в своем ответе на команду "Table Read Fragment" радиочастотная метка должна передать код команды и следующую информацию:

- маркер ответа: новое значение маркера, определенное при успешном выполнении команды "Table Read Fragment". Значение маркера "0x00" зарезервировано для указания конца итерационного процесса;

- реальная длина данных (Actual Read Length): число реально считанных байтов данных, может быть меньше или равна длине данных запроса;

- данные: реально считанные данные из табличной базы данных радиочастотной метки с длиной равной реальной длине считываемых данных.

С помощью команды "Table Read Fragment" производится чтение блоков данных из таблицы базы данных. Считываемая часть таблицы базы данных однозначно определяется значением маркера запроса, полученным от радиочастотной метки в ответ на предшествовавшую команду "Table Get Data" или команду "Table Read Fragment".

Команда "Table Read Fragment" считывает данные только в пределах внесенных в таблицу записей. Если первый байт считываемых данных находится внутри таблицы, но длина данных запроса выходит за пределы последней записи, команда считается действительной, и в ответе радиочастотной метки длина реально считанных данных не может быть больше числа байтов, оставшихся для прочтения в таблице.

Примечание - Если радиочастотная метка идентифицирует данную команду как повторение успешно выполненной предыдущей, то она не выполняет эту команду вновь, а повторно посылает переданный ранее ответ.


Возможные коды ошибки в ответе радиочастотной метки на команду "Table Read Fragment" показаны в таблице 106.


Таблица 106 - Ошибки при выполнении команды "Table Read Fragment"

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

6.3.10.9 Команда "Table Write Fragment"

Для записи фрагмента данных в таблицу радиочастотной метке передается команда "Table Write Fragment", формат которой показан в таблице 107.


Таблица 107 - Формат команды "Table Write Fraqment"

В соответствии с таблицей 107 команда "Table Write Fragment" должна содержать код и субкод команды, а также следующие данные:

- маркер запроса: маркер, полученный в ответ на предшествовавшую команду "Table Add Records", "Table Update Records", "Table Update Fields" или "Table Write Fragment". Структура поля маркера показана в таблице 82;

- длина данных: число байтов записываемых данных. Действительное значение - от 1 до 46 байтов;

- данные: строка байтов, записываемая в табличную базу данных радиочастотной метки.

Получившая команду "Table Write Fragment" радиочастотная метка должна ответить сообщением частного типа, формат которого показан в таблице 108.


Таблица 108 - Формат ответа на команду "Table Write Fragment"

В соответствии с таблицей 108 в своем ответе на команду "Table Write Fragment" радиочастотная метка должна передать код команды и следующую информацию:

- маркер ответа: новое значение маркера, определенное при успешном выполнении команды "Table Write Fragment". Значение маркера "0x00" зарезервировано для указания конца итерационного процесса. Структура поля маркера представлена в таблице 82.

С помощью команды "Table Write Fragment" производится запись блоков байтов данных в таблицу базы данных. Записываемая часть таблицы базы данных однозначно определяется значением маркера запроса, полученным от радиочастотной метки в ответ на предшествовавшую команду "Table Add Records", "Table Update Records", "Table Update Fields" или "Table Write Fragment".

Эта команда делает недействительными любые существующие маркеры для данного идентификатора таблицы. Эта команда также делает недействительными любые результаты поиска в таблице "Query Results", представленные в таблице с идентификатором "0x0000".

Возможные коды ошибки в ответе радиочастотной метки на команду "Table Write Fragment" показаны в таблице 109.

Примечание - Если радиочастотная метка идентифицирует данную команду как повторение успешно выполненной предыдущей, она не выполняет эту команду вновь, а повторно посылает переданный ранее ответ.


Таблица 109 - Ошибки при выполнении команды "Table Write Fragment"

6.3.10.10 Команда "Table Query"

Для поиска таблицы радиочастотной метке передается команда "Table Query", формат которой представлен в таблице 110. Команда "Table Query" может быть отправлена как общая для всех радиочастотных меток одновременно или как частная для одной радиочастотной метки.


Таблица 110 - Формат команды "Table Query"

В соответствии с таблицей 110 команда "Table Query" должна содержать код команды, субкод операции, а также следующие данные:

- идентификатор таблицы: определяет идентификатор, присвоенный таблице;

- идентификатор последовательности: определяет данный элемент запроса в последовательности из нескольких элементов запроса. Если число элементов в последовательности равно N, то первый элемент запроса имеет идентификатор последовательности, равный (N-1), второй элемент запроса - (N-2) и т.д., до идентификатора последовательности, равного нулю, у N-го элемента запроса. Радиочастотная метка должна поддерживать, как минимум, последовательность из четырех элементов запроса со значениями идентификатора последовательности от 3 до 0. Реальный размер последовательности элементов запроса, поддерживаемых радиочастотной меткой, можно запросить с помощью команды "Table Query Size" через элемент блока UDB типа 0x15 (см. 6.3.1.1);

- логический оператор: определяет роль данного элемента запроса в общем запросе. В соответствии с ИСО/МЭК 8859-1 возможны следующие значения логических операторов (функций): "С" - CLEAR ("очистка переменной"), "А" - AND ("и") и "О" - OR ("или");

- номер поля: указывает порядковый номер поля для сравнения. Номер поля должен быть меньше числа полей в таблице;

- оператор отношения: указывает метод сравнения содержания поля с данными команды. В соответствии с ИСО/МЭК 8859-1 возможны следующие значения операторов отношения: "=" (равно), "<" (меньше), ">" (больше) и "!" (не равно);

- длина данных сравнения (Comparison Data Length): указывает длину сравниваемых данных в байтах. Действительное значение длины данных сравнения - от 1 до 32;

- данные сравнения (Comparison Data): указывают байтовый массив для сравнения с содержимым полей таблицы. Длина сравниваемых данных равна длине данных сравнения в байтах и может включать в себя определенный в ИСО/МЭК 8859-1 префикс "*" - знак шаблона подстановки "wildcard".

6.3.10.10.1 Описание синтаксиса команды запроса "Query"

Команда запроса "Query" определяет элемент поиска, который является одним из критериев поиска в последовательности таких критериев.

Полный запрос имеет форму:

{<элемент поиска>} {<элемент поиска>}... {<элемент поиска>}.

Каждый <элемент поиска> имеет форму:

<логический оператор> <логический операнд>.

При этом <логический операнд> имеет форму:

<номер поля> <оператор сравнения> <данные сравнения>.

Логический оператор, номер поля, оператор сравнения и данные указываются в полях команды "Table Query", формат которой показан в таблице 110. По ИСО/МЭК 8859-1 логический оператор обозначается одним из символов: "С", "А" или "О". Номер поля определяет поле таблицы. По ИСО/МЭК 8859-1 оператор сравнения обозначается одним из символов: "=", "<", ">" или "!". Данные сравнения составляют строку данных длиной от 1 до 32 байтов. Угловые и фигурные скобки являются только способом разделения при описании, они не имеют синтаксического значения и не присутствуют в формате команд. Полностью операция поиска определяется последовательностью команд "Table Query".

6.3.10.10.2 Элементы поиска

Каждый элемент поиска в рамках всего поиска соотносится с другими элементами с помощью логических операторов (функций), которые определяют место элементов в булевском алгебраическом выражении. Логические операторы - это логическое "и", логическое "или" и, в особых случаях, оператор "очистки переменной". Логические операторы "и" и "или" - это бинарные операторы с ассоциативностью слева направо одного приоритета выполнения в обычном их булевском значении. Оператор "очистки" CLEAR просто означает, что данный элемент является первым в полной последовательности поиска. Если оператор "очистки" CLEAR является логическим оператором для какого-либо элемента поиска, то весь предшествующий ряд элементов поиска не учитывается, а текущий элемент должен получить первый номер в новой последовательности поиска. При получении действительной команды поиска с оператором "очистки" все ранее полученные результаты поиска должны быть удалены, все существующие записи в таблице с идентификатором "0x00" также должны быть удалены.

Операнды сравнения содержат поле таблицы базы данных, определенное номером поля и данными для сравнения.

6.3.10.10.3 Интерпретация операций поиска

Операция поиска описывается выражением, которое формируется из логических операторов и логических операндов каждого из элементов поиска и читается слева направо.

Так, предположим, что поисковое выражение состоит из четырех элементов поиска и логических операндов А, В, С и D, которые являются логическими операндами первого, второго, третьего, четвертого элементов поиска соответственно.

Полная операция поиска имеет вид:

(CLEAR A) (AND В) (OR С) (AND D).

Это нужно понимать как булевское выражение:

CLEAR (((A AND В) OR С) AND D).

Здесь для каждой записи искомой таблицы каждый логический операнд оценивает значение как "истинно" или "ложно", как это описано ниже. Булевские операторы преобразуют эти значения в одно конечное "истинно" или "ложно" стандартным способом, и оператор CLEAR не влияет на булевское значение полного выражения.

Если конечное значение выражения - "истинно", то найденная в таблице запись включается в таблицу результатов поиска "Query Results Table", как представлено ниже.

6.3.10.10.4 Логические операнды

Логический операнд определяет, каким образом каждая запись искомой таблицы проверяется для включения в набор совпадения записей. Номер поля логического операнда определяет, какое поле каждой записи должно быть проверено. Данные сравнения определяют значение строки, по которой производится сравнение с содержимым таблицы. Оператор отношения определяет способ сравнения содержания поля и данных сравнения, двух подлежащих сравнению операндов отношения в операторе отношения. Кроме того, первый байт данных сравнения влияет на метод сравнения. Если этот байт обозначен знаком "*" по ИСО/МЭК 8859-1, то проводится сравнение по шаблону подстановки "wildcard", в противном случае сравнение производится с полным совпадением.

6.3.10.10.5 Сравнение с полным совпадением

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

Например, следующее выражение сравнения оценивается как "истинно":

abc = abc.

Следующие выражения сравнения оцениваются как "ложно":

abc < abc;

abdb < abce;

abc > abc;

abc! abc.

Если оператором отношения является "!", то сравнение с полным совпадением производится также, как для оператора отношения "=", но с противоположным результатом. Любое сравнение, в котором оператор "=" даст результат "истинно", с оператором "!" будет иметь результат "ложно".

Следующие сравнения оцениваются как "истинно":

abc! abcd;

abc! ABC;

abc! abd;

abc! ab.

Следующее сравнение оценивается как "ложно":

abc! abc.

Если оператором отношения является "<" или ">", то сравнение с полным совпадением операндов отношения производится побайтово, как для оператора "=", до обнаружения первого несовпадения. Если несовпадений нет, то логическому операнду присваивается значение "ложно". Несовпадающие байты сравниваются согласно оператору отношения. Если оператором отношения является "<" и байтов в содержании поля меньше, чем байтов из данных сравнения, то логический операнд оценивается как "истинно". Если оператором отношения является ">" и байтов в содержании поля больше, чем байтов из данных сравнения, то логический операнд принимает значение "истинно". Для операторов неравенства "<" или ">", если длина одного операнда отношения меньше длины другого операнда, для более короткого операнда в целях сравнения добавляется дополнительный конечный байт с меньшим значением, чем минимальное возможное значение байта.

Следует иметь в виду, что, поскольку данные сравнения ограничены 32 байтами, то значение сравнения для полей длиннее 32 байтов оцениваются как "ложно" при операторе "=" и полном сравнении и как "истинно" при операторе "!" и полном сравнении.

Так, следующие сравнения имеют значения "истинно":

abb < abc;

aad < abc;

ab < abc;

abc < ad;

abc > abb;

abc > aad;

abc > ab;

ad > abc;

abc! abd;

abc! ab.

Следующие сравнения оцениваются как "ложно":

abc < abc;

abdb < abce;

abc > abc;

abc! abc.

6.3.10.10.6 Сравнение с шаблоном подстановки "wildcard"

Для сравнения с шаблоном подстановки "wildcard" с оператором отношения "=" производится сравнение содержания поля таблицы, начиная с первого байта, и данных сравнения, начиная с байта, следующего за символом "*", на основе сдвига, как при полном сравнении, до достижения конца поля данных.

Таким образом, стартуя от начала поля данных и смещаясь вправо по одному байту до конца поля данных, байты в поле данных таблицы на длине данных сравнения сравниваются с байтами данных сравнения на длине данных сравнения, и оценивается полнота совпадения. Если полное совпадение установлено, сравнение прекращается. Если полное совпадение установлено для оператора отношения "=", то результат сравнения оценивается как "истинно", в противном случае результат оценивается как "ложно". Результат для оператора "!" оценивается как "ложно" при обнаружении полного совпадения, в противном случае он оценивается как "истинно". Сравнения с шаблоном подстановки "wildcard" с операторами "<" или ">" невыполнимы, как и сравнения с шаблоном подстановки, для которого сравниваемые данные определяются единственно знаком "*".

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

Следующие сравнения оцениваются как "истинно":

abcde = *bcd;

abcbcde = *bcd;

abcecd!*bcd.

Следующие сравнения оцениваются как "ложно":

abcde! *bcd;

abce = *bcd.

6.3.10.10.7 Ошибки поиска

Возможные коды ошибок при выполнении команды поиска приведены в таблице 111.


Таблица 111 - Ошибки при выполнении команды "Table Query"

6.3.10.10.8 Завершение операции поиска

После получения последней команды "Table Query" с идентификатором последовательности, равным нулю, радиочастотная метка имеет полный набор критериев поиска. Радиочастотная метка должна выполнять полный поиск в каждой записи таблицы, обозначенной идентификатором таблицы, начиная с номера записи "0" и далее по всем записям таблицы.

Полные результаты операции поиска записываются в таблицу "Query Results Table" (идентификатор таблицы - "0x0000"). Таблица "Query Results Table" имеет формат записей с одним полем длиной 2 байта. Каждое двухбайтовое поле/запись в таблице "Query Results Table" содержит номер записи, совпадающей с критерием поиска записи в искомой таблице. Если номеров совпадающих записей несколько, они располагаются в порядке возрастания. Записи таблицы с идентификатором "0x0000" передаются УСО в ответ на команды "Table Get Data" и "Table Read Fragment". Номер записи для каждой совпадающей записи должен передаваться как отдельная запись, начиная со старшего байта.

6.3.10.10.9 Поиск с помощью общей или частной команды "Table Query"

Команда "Table Query" существует в общем и частном видах. Как описано в 6.2.6.1, вид команды - общий или частный - определяет значение поля опций пакета. На любую общую команду "Table Query" радиочастотная метка не отвечает даже в случае обнаружения ошибки.

Получив не окончательную в серии частную команду "Table Query" с ненулевым идентификатором последовательности, радиочастотная метка должна проверить ее действительность. На действительную начальную или промежуточную в последовательности команду "Table Query" радиочастотная метка отвечает частным сообщением, содержащим код команды, как показано в таблице 112. Никаких данных в ответе радиочастотной метки не передается, если не обнаружена ошибка. Ответ показывает, что радиочастотная метка успешно получила действительный элемент поиска, однако никаких данных о результатах операции поиска еще нет.


Таблица 112 - Формат ответа на промежуточную команду "Table Query"

По завершении последовательности частных команд поиска радиочастотная метка отвечает сообщением частного вида, формат которого показан в таблице 113.


Таблица 113 - Формат промежуточного ответа на окончательную частную команду "Table Query"

В соответствии с таблицей 113 в своем ответе на окончательную частную команду "Table Query" радиочастотная метка должна передать код команды и следующую информацию:

- число совпадающих записей (Number of Records matched): число записей в искомой таблице, которые удовлетворяют критериям поиска. Формат этого значения - целое шестнадцатибитовое число без знака. Если никаких совпадений не найдено, значение поля равно нулю;

- индекс первой совпадающей записи (Index of first matched record): содержит номер первой совпадающей записи в искомой таблице, удовлетворяющей критерию поиска. Если никаких совпадений не найдено, значение поля равно нулю.

Если результаты поиска не дали совпадений, то в передаваемом ответе на окончательную частную команду "Table Query" число совпадающих записей и номер первой совпадающей записи должны быть равны нулю.

После выполнения последовательности частных команд "Table Query" УСО может получить результаты поиска в виде данных таблицы "Query Results Table" (идентификатор таблицы - "0x0000") с помощью команд "Table Get Data" и "Table Read Fragment".

6.3.10.10.10 Получение результатов поиска с помощью общей команды "Collection with UDB"

Команду общего вида "Collection with UDB" можно использовать для получения от радиочастотной метки результатов поиска после завершения последовательности команд "Table Query". Для извлечения результатов поиска УСО может отправить команду "Collection with UDB" с полем типа блока UDB, равным "0x02" (см. таблицу 40). Радиочастотная метка ответит сообщением со своим серийным номером и элементом результатов поиска "Table Query Results" (см. таблицу 36). Элемент "Table Query Results" содержит номер искомой таблицы, число совпадающих записей и номер первой совпадающей записи. Если поиск не дал никаких совпадений, то число совпадающих записей и номер первой совпадающей записи равны нулю. После успешно выполненного поиска УСО может запросить информацию о поиске в виде таблицы "Query Results Table" (идентификатор таблицы - "0x0000") в ответ на команды "Table Get Data" и "Table Read Fragment".
_______________
В оригинале ИСО/МЭК 18000-7:2009 ошибочно приведена ссылка на таблицу 36.

6.3.10.10.11 Удаление результатов поиска

Результаты выполнения команды "Table Query" заносятся в таблицу "Query Results Table" (зарезервированный идентификатор таблицы - "0x0000"). Любая команда обращения к базе данных, которая изменяет любые таблицы базы данных ("Table Add Records", "Table Update Records", "Table Update Fields" или "Table Delete Record"), стирает все записи в таблице результатов поиска. В ответе на любые последующие команды запроса "Table Get Properties" в поле текущего числа записей таблицы результатов поиска будет нулевое значение числа записей, в настоящее время находящихся в таблице.

6.3.11 Команда "Веер ON/OFF"

Для включения и выключения режима звукового сигнала радиочастотной метке передается команда "Веер ON/OFF", формат которой показан в таблице 114.


Таблица 114 - Формат команды "Веер ON/OFF"

В соответствии с таблицей 114 команда "Веер ON/OFF" должна содержать код команды, а также следующие данные:

- включение/выключение сигнала: параметр, который включает режим звукового сигнала радиочастотной метки (значение параметра - "0x01") или выключает этот режим (значение параметра - "0x00").

Получившая команду "Веер ON/OFF" радиочастотная метка должна ответить частным сообщением с кодом команды, как указано в таблице 115, не передавая при этом никаких данных, если только при выполнении команды не были обнаружены ошибки.


Таблица 115 - Формат ответа на команду "Веер ON/OFF"

Команда "Веер ON/OFF" включает или выключает режим звукового сигнала радиочастотной метки. Когда звуковой режим включен, радиочастотная метка издает звуковой сигнал до тех пор, пока данный режим не будет выключен или пока радиочастотная метка не вернется в спящее состояние.

Возможные коды ошибок при выполнении команды приведены в таблице 116.


Таблица 116 - Ошибки при выполнении команды "Веер ON/OFF"

6.3.12 Применение датчиков

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

6.3.12.1 Блок расширения применения блока UDB для датчиков

Изготовитель может записать статус датчика в блок UDB, используя формат блока расширения применения (см. таблицу 41 и описание в 6.3.1)
_______________
Исключен повтор предложения, приведенный в оригинале ИСО/МЭК 18000-7:2009.


Блок расширения применения обеспечивает гибкость формирования данных о статусе датчика в зависимости от применения и сложности компоновки датчика. Так, один или несколько элементов TLD, формат которых определен в таблице 29, могут быть определены в блоке UDB.

6.3.12.2 Хранение данных датчика

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

6.3.12.3 Команды получения информации о статусе датчиков и данных датчиков

Для получения информации о статусе датчиков в блоке UDB УСО может использовать следующие стандартные команды:

- "Collection with UDB" (код команды "0x1F");

- "Read UDB" (код команды "0x70").

Результаты регистрации активности датчиков можно запросить с помощью следующих команд:

- "Table Get Data" (код команды "0x26+0x06"), а затем - "Table Read Fragment" (код команды "0x26+0x08");

- "Table Query" (код команды "0x26+0x10").

Стандартные форматы ответных сообщений отправляются назад к УСО с запрошенной информацией.

6.3.12.4 Характеристики и форматы данных датчиков

Данные датчиков хранятся в формате, установленном в IEEE 1451.

Примечание - Форматы данных датчиков приведены в ИСО/МЭК 24753.

6.3.12.5 Физический интерфейс между датчиком и радиочастотной меткой

Физический интерфейс между датчиком и радиочастотной меткой должен удовлетворять требованиям, изложенным в IEEE 1451.7
_______________
Базовым стандартом для будущих применений сенсорных технологий в области радиочастотной идентификации является IEEE 1451.7. Ожидается, что пересмотр настоящего стандарта в будущем может потребовать соблюдения требований IEEE 1451.7 к физическому интерфейсу. Текущая версия IEEE 1451.7 не отвечает особенностям технологий активных радиочастотных меток, ввиду этого изготовители радиочастотных меток призываются к активному участию в переработке текущей версии IEEE 1451.7.

6.4 Опрос радиочастотных меток и разрешение коллизий

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

Понятия "все радиочастотные метки" и "множество радиочастотных меток" относятся к радиочастотным меткам, находящимся в рабочей области УСО.

Основные положения

Для идентификации радиочастотных меток в рабочей области УСО используется процесс опроса радиочастотных меток. Это итерационный процесс, который включает в себя методы координирования ответов, поступающих от множества радиочастотных меток, и управления коллизиями. Коллизии происходят при одновременном ответе нескольких меток. Законченный процесс опроса называют "полной последовательностью опроса" (Complete Collection Sequence).

Опрос радиочастотных меток

На рисунке 5 показана полная последовательность опроса, состоящая из периода пробуждения ("Wake Up Period"; WP) и серии периодов опроса ("Collection Period"; СР). Каждый период опроса состоит из периода синхронизации ("Synchronization Period"; SP), периода прослушивания ("Listen Period"; LP) и периода опознания ("Acknowledge Period"; АР).

Рисунок 5 - Диаграмма синхронизации по времени УСО и радиочастотных меток

Рисунок 5 - Диаграмма синхронизации по времени УСО и радиочастотных меток

Период пробуждения (WP): период времени, в течение которого УСО передает один или несколько сигналов пробуждения "Wake Up" для перевода всех радиочастотных меток в состояние готовности "Ready". Сигнал "Wake Up" определен в 6.1. Каждая полная последовательность содержит только один период пробуждения.

Период опроса (СР): периоды времени, в течение которых радиочастотные метки идентифицируются и опознаются. Периоды опроса повторяются до тех пор, пока не заканчивается идентификация всех отвечающих радиочастотных меток. Каждый период опроса состоит из периода синхронизации (SP), периода прослушивания (LP) и периода опознания (АР).

Период синхронизации (SP): период времени, в течение которого УСО передает множеству радиочастотных меток в своей рабочей области общую команду "Collection". Все радиочастотные метки должны использовать для взаимной синхронизации конец пакета полученной от УСО общей команды.

Период прослушивания (LP): время ожидания УСО ответных сообщений радиочастотных меток. Этот период разделяется на временные слоты ("Time Slots"; TS) - временные окна для ответов радиочастотных меток. Каждая радиочастотная метка выбирает для ответа случайный номер слота и задерживает передачу своего сообщения до наступления выбранного момента времени (временного слота).

Период опознания (АР): период времени, в течение которого УСО опознает ответившие метки и может запросить у них дополнительные данные. От каждой радиочастотной метки, идентифицированной УСО на протяжении предыдущего периода прослушивания, УСО может получить дополнительные данные, а затем дать радиочастотной метке команду "Sleep" и перевести ее в спящее состояние.

Период опроса ("Collection Period"; СР)

На рисунке 6 показан период опроса СР, состоящий из периодов синхронизации, прослушивания и опознания. Период прослушивания делится на слоты, показанные на рисунке 5. В команде опроса длительность периода прослушивания задается с помощью параметра размера окна ("Wndow Size").

Рисунок 6 - Подробная диаграмма синхронизации антиколлизионного алгоритма

Рисунок 6 - Подробная диаграмма синхронизации антиколлизионного алгоритма

Период прослушивания (LP) вычисляется как произведение 57,3 мс на размер окна, которое затем округляется до целого числа миллисекунд.

Период прослушивания (LP) разделяется на временные слоты - окна ответов отдельных радиочастотных меток. Длительность слота должна быть достаточной для передачи радиочастотной меткой сообщения максимальной длины и иметь запас на рассогласованность во времени радиочастотной метки и УСО. Максимальная длина сообщения радиочастотной метки определяется параметром максимальной длины пакета, который входит в команду "Collection with Universal Data Block".

Длительность слота вычисляется как максимальная длина пакета, умноженная на 324 мкс/байт, плюс 3332 мкс. Затем эта сумма округляется до целого числа миллисекунд. При этом 324 мкс/байт - это скорость передачи каждого байта (т.е. скорость передачи 8 битов данных и 1 стопового бита с битовым периодом 36 мкс каждый), а 3332 мкс - это сумма длительности преамбулы сообщения радиочастотной метки (1296 мкс), длительности сигнала - признака конца пакета (36 мкс) и запаса времени на каждый слот (2 мс).

Число временных слотов, которые могут входить в период прослушивания, определяется как отношение длительности периода прослушивания к длительности временного слота, которое затем округляется до целого числа.

Период пробуждения ("Wake Up Period"; WP)

Пошаговое описание полной последовательности опроса иллюстрируется на рисунке 5.

Период пробуждения (WP):

- УСО передает сигнал "Wake Up" всем радиочастотным меткам в своей рабочей области;

- радиочастотная метка переходит из спящего режима в состояние готовности "Ready" и ждет команды от УСО.

Период опроса (СР):

- УСО: передает радиочастотным меткам команду "Collection with Universal Data Block". Команда включает в себя параметры размера окна и максимальной длины пакета;

- радиочастотная метка, находясь в состоянии "Ready", принимает и декодирует команду "Collection with Universal Data Block", рассчитывает продолжительность периода прослушивания, длительность временного слота, а также число временных слотов. Выбирает случайным образом временной слот и ждет начала выбранного слота для передачи ответного сообщения;

- УСО рассчитывает продолжительность периода прослушивания, длительность временного слота, а также число временных слотов. Начинает прослушивание ответов радиочастотных меток;

- радиочастотная метка в начале выбранного слота передает сообщение УСО. Радиочастотная метка должна отвечать только один раз в данный период опроса;

- УСО получает действительный ответ радиочастотной метки с правильным значением кода CRC или получает коллизию (одновременные ответы нескольких радиочастотных меток в одном временном слоте), или не получает никакого ответа, так как в данном временном слоте радиочастотные метки не отвечают (пустой временной слот);

- УСО продолжает прослушивание оставшихся слотов до конца периода прослушивания;

- УСО может послать каждой метке, от которой получено действительное сообщение, частную команду "Read Universal Data Block" и запросить оставшиеся блоки UDB. Затем УСО посылает данной метке команду "Sleep";

- радиочастотная метка отвечает на полученные от УСО частные команды "Read Universal Data Block";

- радиочастотная метка при получении команды "Sleep" выходит из состояния "Ready" и не отвечает на дальнейшие команды УСО до получения нового сигнала "Wake Up";

- если во время прошедшего периода опроса возникло слишком много коллизий или значительная часть периода оказалась незадействованной, то УСО должно подстроить ширину канала связи, передав новые параметры в команде сбора данных "Collection". Если число коллизий слишком велико, то УСО должно увеличить параметр размера временного окна в команде "Collection with Universal Data Block". Если коллизий нет или их мало, то УСО должно уменьшить параметр размера временного окна;

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

Рисунок 7 - Последовательность и синхронизация процесса опроса

Рисунок 7 - Последовательность и синхронизация процесса опроса

6.5 Сбор данных множества пакетов блока UDB

В настоящем разделе приведен простой пример сбора данных множества пакетов блока UDB. УСО инициирует процесс путем передачи общей команды "Collection with Universal Data Block". Принявшие команду радиочастотные метки отвечают пакетами, которые включают в себя идентификатор радиочастотной метки и первую часть блока UDB запрошенного типа. УСО может затем затребовать остальные данные путем посылки частной команды любой из идентифицированных на первой стадии радиочастотных меток.

1) На рисунке 8 показана схема сбора данных УСО с помощью пакета команды "Collection with UDB". Это пакет общей команды, на который отвечают все получившие его радиочастотные метки.

Рисунок 8 - Общая команда "Collection with UDB" для начального опроса радиочастотных меток

Рисунок 8 - Общая команда "Collection with UDB" для начального опроса радиочастотных меток

2) На рисунке 9 показан пакет ответного сообщения радиочастотной метки на общую команду "Collection with UDB" с кодом команды 0x1F. Формат ответа такой же, как для всех общих команд.

Рисунок 9 - Ответ радиочастотной метки на команду "Collection with UDB"

Рисунок 9 - Ответ радиочастотной метки на команду "Collection with UDB"

3) На рисунке 10 показана частная команда "Read Universal Data Block", адресованная радиочастотной метке, идентифицированной в ходе предыдущего процесса опроса. Частная команда отправляется конкретной радиочастотной метке, используя идентификационное значение радиочастотной метки, полученное в ходе предыдущего процесса опроса. Следует отметить, что смещение в поле блока UDB должно содержать значение, равное числу байтов данных блока UDB, переданных радиочастотной меткой в ответ на общую команду (число N на рисунке 9 выше).

Рисунок 10 - Частная команда УСО конкретной радиочастотной метке для получения оставшейся части данных блока UDB

Рисунок 10 - Частная команда УСО конкретной радиочастотной метке для получения оставшейся части данных блока UDB

4) На рисунке 11 показано сообщение радиочастотной метки в ответ на частную команду "Read Universal Data Block". Ответ содержит вторую часть сообщения блока UDB в формате частного (направленного) пакета.

Рисунок 11 - Ответ радиочастотной метки на запрос дополнительной информации с помощью частной команды "Read UDB"

Рисунок 11 - Ответ радиочастотной метки на запрос дополнительной информации с помощью частной команды "Read UDB"

6.6 Физические параметры и параметры управления множественным доступом ("Media Access Control"; MAC)

6.6.1 Линия связи УСО с радиочастотной меткой

Параметры связи УСО с радиочастотной меткой обобщены в таблице 117.


Таблица 117 - Параметры линии связи УСО с радиочастотной меткой

6.6.2 Линия связи радиочастотной метки с УСО

Параметры линии связи радиочастотной метки с УСО представлены в таблице 118.


Таблица 118 - Параметры линии связи радиочастотной метки с УСО

6.6.3 Протокол передачи данных

Параметры протокола передачи данных представлены в таблице 119.


Таблица 119 - Параметры протокола передачи данных

_______________
В настоящее время общепринятым обозначением протокола связи "УСО говорит первым" считается "ITF" (от английского "Interrogator Talks First") вместо указанного в оригинале ИСО/МЭК 18000-7:2009 обозначения "RTF" (от английского "Reader Talks First").

6.6.4 Антиколлизионные параметры

Параметры разрешения коллизий (антиколлизии) представлены в таблице 120.


Таблица 120 - Антиколлизионные параметры

Приложение А (обязательное). Совместимость различных стандартов применения на основе настоящего стандарта

Приложение А
(обязательное)

В таблице А.1 показаны различные идентификаторы протокола для иллюстрации преемственности протокольных версий.


Таблица А.1 - Идентификаторы протокола

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

Во всех этих стандартах применения используются одинаковые протоколы сигнального уровня, но структуры команд, полей данных и ответов меток, а также наборы команд могут быть различны в зависимости от конкретного применения. Командой сбора данных является команда "Collection with UDB". В этом приложении понятия "команда "Collection" и "команда "Collection with UDB" взаимозаменяемы. В настоящем стандарте определены две основные команды: "Collection" и "Sleep", которые должны поддерживаться всеми стандартами применения. Все другие команды должны поддерживаться системами, полностью соответствующими настоящему стандарту, но не являются необходимыми для других стандартов применения.

Когда УСО передает сигнал "Wake Up", его команду должны выполнять все радиочастотные метки, поддерживающие радиоинтерфейс в соответствии с настоящим стандартом.

Затем УСО может передавать различные команды, в том числе специфические для конкретного применения. Когда УСО необходимо обнаружить в своей рабочей области все активные радиочастотные метки, оно передает команду сбора данных, определенную в настоящем стандарте. На основную команду "Collection" должны отвечать все радиочастотные метки, требования к которым установлены в стандартах применения, разработанных на основе настоящего стандарта, но формат ответа может быть определен в стандарте на уровень линии передачи данных для конкретного применения.

Радиочастотные метки должны также поддерживать определенные в данных технических требованиях команды "Sleep".

Рисунок А.1 - Запрос и ответ по конкретному идентификатору протокола

Рисунок А.1 - Запрос и ответ по конкретному идентификатору протокола

Рисунок А.2 - Совместимость радиочастотных меток для различных применений

Рисунок А.2 - Совместимость радиочастотных меток для различных применений

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов и документов национальным стандартам Российской Федерации

Приложение ДА
(справочное)

Таблица ДА.1

Приложение ДБ (справочное). Перевод на русский язык наименований команд, сигналов, ошибок, физических параметров и параметров управления множественным доступом по ИСО/МЭК 18000-7

Приложение ДБ
(справочное)

Перевод на русский язык наименований команд по ИСО/МЭК 18000-7 приведен в таблице ДБ.1.


Таблица ДБ.1 - Перевод на русский язык наименований команд по ИСО/МЭК 18000-7

Перевод на русский язык наименований сигналов по ИСО/МЭК 18000-7 приведен в таблице ДБ.2.


Таблица ДБ.2 - Перевод на русский язык наименований сигналов по ИСО/МЭК 18000-7

Перевод на русский язык наименований ошибок по ИСО/МЭК 18000-7 приведен в таблице ДБ.3.


Таблица ДБ.3 - Перевод на русский язык наименований ошибок по ИСО/МЭК 18000-7

Перевод на русский язык наименований основных физических параметров канала связи между УСО и радиочастотной меткой по ИСО/МЭК 18000-7 приведен в таблице ДБ.4.


Таблица ДБ.4 - Перевод на русский язык наименований основных физических параметров канала связи между УСО и радиочастотной меткой по ИСО/МЭК 18000-7

Перевод на русский язык наименований основных физических параметров протокола связи между УСО и радиочастотной меткой по ИСО/МЭК 18000-7 приведен в таблице ДБ.5.


Таблица ДБ.5 - Перевод на русский язык наименований основных физических параметров протокола связи по ИСО/МЭК 18000-7

Перевод на русский язык наименований основных физических параметров антиколлизионного алгоритма по ИСО/МЭК 18000-7 приведен в таблице ДБ.6.


Таблица ДБ.6 - Перевод на русский язык наименований основных параметров антиколлизионного алгоритма по ИСО/МЭК 18000-7

Библиография

____________________________________________________________________________________
УДК 681.5.015:621.3:006:354 ОКС 35.040 П85

Ключевые слова: радиочастотная идентификация для управления предметами, активный радиоинтерфейс, диапазон частот, 433 МГц
____________________________________________________________________________________



Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2014