Получите образец ТУ или ГОСТа за 3 минуты

Получите ТУ или ГОСТ на почту за 4 минуты

ГОСТ Р ИСО/МЭК 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. ИСО и МЭК не рассматривают вопросов подтверждения, срока действия и области применения указанных патентных прав.

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

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

Номер патента

Наименование патента

Держатель патента

Контактная информация

Разделы настоящего стандарта, имеющие отношение к данному патенту

US 5640151

“Система связи для радиочастотных меток” (“Communication system for communicating with tags”)

Компания “Savi Technology” (США)

Hurst Arthur, VP, General Counsel, Savi Technology, Inc., 351 East Evelyn Ave., Mountain View, CA 94041, USA

6.2.6

US 5686902

“Система связи для радиочастотных меток” (“Communication system for communicating with tags”)

Компания “Savi Technology” (США)

Hurst Arthur, VP, General Counsel, Savi Technology, Inc., 351 East Evelyn Ave., Mountain View, CA 94041, USA

6.2.6

US 11/432684

“Способ и устройство для эффективной передачи данных радиочастотной меткой” (“Method and apparatus for efficient data transmission from a tag”)

Компания “Savi Technology” (США)

Hurst Arthur, VP, General Counsel, Savi Technology, Inc., 351 East Evelyn Ave., Mountain View, CA 94041, USA

ЕР 0467036

“Способ и устройство для радиочастотной идентификации и отслеживания предметов” (“Method and apparatus for radio-identification and tracking”)

Компания “Savi Technology” (США)

Hurst Arthur, VP, General Counsel, Savi Technology, Inc., 351 East Evelyn Ave., Mountain View, CA 94041, USA

6.2.6

US 6002344

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

CA 2310623

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

CN 98812462.9

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

DE 98960332.9

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

EP 98960332.9

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

FR 98960332.9

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

GB 98960332.9

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

HK 01101416.3

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

IL 136.220

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

IT 98960332.9

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

JP 2000-521687

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

US 7035818

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

US 10/725010

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

US 10932279

“Система и метод электронной инвентаризации” (“System and method for electronic inventory”)

Компания “Symbol Technologies” (США)

Aaron B. Bernstein, VP, Deputy General Counsel Intellectual Property, 1 Motorola Plaza, MS A6, Holtsville, NY 11561, USA

6.2

US 6470045

“Протокол связи между трансивером и транспондерами или трансивером, связанным с данным устройством” (“Communication protocol between a transceiver unit and transponders or transceiver associated with said unit”)

Компания “EM Microelectronic Marin SA” (Швейцария)

G. Meusburger, IP Manager, Rue des Sors, CH-2074, Marin, Switzerland

JP 10-256493

“Протокол связи между трансивером и транспондерами или трансивером, связанным с данным устройством” (“Communication protocol between a transceiver unit and transponders or transceiver associated with said unit”)

Компания “EM Microelectronic Marin SA” (Швейцария)

G. Meusburger, IP Manager, Rue des Sors, CH-2074, Marin, Switzerland

EP 0 902 546
Appl. No. 97115772.2

“Протокол связи между трансивером и транспондерами или трансивером, связанным с данным устройством” (“Communication protocol between a transceiver unit and transponders or transceiver associated with said unit”)

Компания “EM Microelectronic Marin SA” (Швейцария)

G. Meusburger, IP Manager, Rue des Sors, CH-2074, Marin, Switzerland

US 6784787
Granted EP 1 031 046
Granted EP 1 291 671
Granted EP Appl. 05 017 862.3 Pending

“Системы идентификации” (“Identification systems”)

Компания “Zebra Technologies” (США)

Eric McAlpine, IP Counsel, Legal Department, 333 Corporate Woods Parkway, Vernon Hills, IL 60061-3109, USA

US 6480143 Granted
ЕР 1 001 366 Granted

“Системы электронной идентификации” (“Electronic identification systems”)

Компания “Zebra Technologies” (США)

Eric McAlpine, IP Counsel, Legal Department, 333 Corporate Woods Parkway, Vernon Hills, IL 60061-3109, USA

US 5680459 Granted

“Пассивный транспондер” (“Passive transponder”)

Компания “Zebra Technologies” (США)

Eric McAlpine, IP Counsel, Legal Department, 333 Corporate Woods Parkway, Vernon Hills, IL 60061-3109, USA

US 6198381 Granted
JP 10-272945 Pending

“Модель режима возврата с задержкой для систем электронной идентификации” (“Delayed reset mode model for electronic identification system”)

Компания “Zebra Technologies” (США)

Eric McAlpine, IP Counsel, Legal Department, 333 Corporate Woods Parkway, Vernon Hills, IL 60061-3109, USA

US 5537105 Granted
US 5966083 Granted
US 5995017 Granted

“Системы электронной идентификации” (“Electronic identification systems”)

Компания “Zebra Technologies” (США)

Eric McAlpine, IP Counsel, Legal Department, 333 Corporate Woods Parkway, Vernon Hills, IL 60061-3109, USA

US 7375637 Granted

“Способы и устройство для снижения энергопотребления активного транспондера” (“Methods and apparatus for reducing power consumption of an active transponder”)

Питтсбургский университет (США)

Marc S. Malandro, Ph. D., CLP, University of Pittsburgh, 200 Gardner Steel Conference Center, Thackeray & O’Hara Streets, Pittsburgh, PA 15260, USA

US 11/678296 Pending

“Способы и устройство для переключения транспондера (радиочастотной метки) в активное состояние и аналогичные системы управления ресурсами” (“Methods and apparatus for switching a transponder to an active state, and asset management systems employing same”)

Питтсбургский университет (США)

Marc S. Malandro, Ph. D., CLP, University of Pittsburgh, 200 Gardner Steel Conference Center, Thackeray & O’Hara Streets, Pittsburgh, PA 15260, USA

US 61/099977 Pending

“Система и способ отслеживания перемещения предметов в режиме реального времени” (“System and method for real time asset location and tracking”)

Питтсбургский университет (США)

Marc S. Malandro, Ph. D., CLP, University of Pittsburgh, 200 Gardner Steel Conference Center, Thackeray & O’Hara Streets, Pittsburgh, PA 15260, USA

US 6563417 Granted
US 6917291 Granted
US 7053777 Granted

“Опрос, мониторинг и обмен данными в системах с радиочастотными метками” (“Interrogation, monitoring and data exchange using RFID Tags”)

Компания “Identec Solutions” (Австрия)

Stefan Schwiers, СТО, R&D Department, Identec Solutions AG, Millennium Park 2, 6890 Lustenau, Austria

6.3.12

EP 99117640.5-
2215
Granted
DE 59904147.1-
08 Granted
GB/FR/CH/NL/AT
99117640.5-
2215 Granted

“Системы мониторинга, отслеживания и обработки перемещаемых объектов” (“System for monitoring, tracking, and handling of objects”)

Компания “Identec Solutions” (Австрия)

Stefan Schwiers, СТО, R&D Department, Identec Solutions AG, Millennium Park 2, 6890 Lustenau, Austria

6.3.12

US 7345576 Granted

“Способ и устройство разрешения коллизий (обнаружения единственного контейнера) среди множества транспортируемых единиц, оснащенных радиочастотными метками” (“Method and apparatus for resolving RFID based object traffic transactions to single container in the presence of a plurality of containers”)

Компания “Identec Solutions” (Австрия)

Stefan Schwiers, СТО, R&D Department, Identec Solutions AG, Millennium Park 2, 6890 Lustenau, Austria

6.3.12

Компания “Impinj” (США)

Chris Diorio, СТО, 701 N. 34th Street, Suite 300, Seattle, WA 98103, USA

Компания “lntermec” (США)

Phyllis T Turner-Brim, Esq., Legal Department, Intermec IP Corporation, 6001 36th Ave. W, Everett, WA 98203, USA

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

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

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]
_______________
Рекомендации по ограничению воздействия переменных во времени электрических, магнитных и электромагнитных полей (до 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)
_______________
по безопасным уровням воздействия на человека радиочастотных электромагнитных полей от 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 – Формат команды УСО ко всем радиочастотным меткам (общая команда)

Идентификатор протокола

Опции пакета

Длина пакета

Идентификатор сеанса

Код команды

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

Код CRC

0x40

1 байт

1 байт

2 байта

1 байт

N байтов

2 байта

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

Идентификатор протокола

Опции пакета

Длина пакета

Иденти-
фикатор изготови-
теля
радиоча-
стотной метки

Серий-
ный номер радиоча-
стотной метки

Иденти-
фикатор сеанса

Код команды

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

Код CRC

0x40

1 байт

1 байт

2 байта

4 байта

2 байта

1 байт

N байтов

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 – Поле опций пакета

Бит

7

6

5

4

3

2

1

0

Резерв

Резерв

Резерв

Резерв

Резерв

“1”

“0”: общий запрос всем радиочастотным меткам (серийный номер радиочастотной метки и идентификатор изготовителя радиочастотной метки отсутствуют)

“1”: частный запрос радиочастотной метке (серийный номер радиочастотной метки и идентификатор изготовителя радиочастотной метки присутствуют)

Резерв

Бит 2 поля опций пакета всегда имеет фиксированное значение “1” для совместимости версий.

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

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 – http://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 – Коды команд

Код команды и субкод команды (чтение/запись)

Название команды

Тип команды

Обязательная или дополнительная

Описание

УСО

Радиочастотная метка

0x1F/Нет

“Collection with Universal Data Block”

Общая

Обязательная

Обязательная

Запрос всех идентификаторов радиочастотных меток и универсальных блоков данных

Нет/0х15

“Sleep”

Частная

Обязательная

Обязательная

Перевод радиочастотной метки в спящее состояние

Нет/0х16

“Sleep All But”

Общая

Обязательная

Обязательная

Перевод в спящее состояние всех радиочастотных меток, кроме одной

0x13/0x93

“User ID”

Частная

Обязательная

Дополнительная

Установка пользовательского идентификатора (от 1 до 60 байтов)

0x09/0x89

“Routing Code”

Частная

Обязательная

Обязательная

Чтение и запись маршрутного кода

0х0С/Нет

“Firmware Version”

Частная

Обязательная

Дополнительная

Запрос присвоенного изготовителем номера версии радиочастотной метки

0х0Е/Нет

“Model Number”

Частная

Обязательная

Дополнительная

Запрос присвоенного изготовителем номера модели радиочастотной метки

0x60/0хЕ0

“Read /Write Memory”

Частная

Обязательная

Дополнительная

Чтение и запись пользовательской памяти

Нет/0х95

“Set Password”

Частная

Обязательная

Дополнительная

Установка пароля радиочастотной метки (длиной 4 байта)

Нет/0х97

“Set Password Protect Mode”

Частная

Обязательная

Дополнительная

Установка/снятие защиты пароля (см. 6.3.4)

Нет/0х96

“Unlock”

Частная

Обязательная

Дополнительная

Деблокировка радиочастотной метки с паролем

0x70/Нет

“Read Universal Data Block”

Частная

Обязательная

Обязательная

Чтение универсального блока данных

0x26+0x01

“Table Create”

Частная

Обязательная

Дополнительная

Создание таблицы базы данных

0x26+0x02

“Table Add Records”

Частная

Обязательная

Дополнительная

Подготовка к добавлению новых записей в табличную базу данных

0x26+0x03

“Table Update Records”

Частная

Обязательная

Дополнительная

Подготовка к модификации определенных табличных записей

0x26+0x04

“Table Update Fields”

Частная

Обязательная

Дополнительная

Подготовка к обновлению определенных полей табличных записей

0x26+0x05

“Table Delete Records”

Частная

Обязательная

Дополнительная

Удаление существующих записей из существующих таблиц

0x26+0x06

“Table Get Data”

Частная

Обязательная

Дополнительная

Подготовка чтения определенных табличных записей

0x26+0x07

“Table Get Properties”

Частная

Обязательная

Дополнительная

Определение общего числа записей и максимального числа записей таблицы

0x26+0x08

“Table Read Fragment”

Частная

Обязательная

Дополнительная

Чтение блока данных из таблицы после команды “Table Get Data”

0x26+0x09

“Table Write Fragment”

Частная

Обязательная

Дополнительная

Запись блока данных в таблицу после команд “Table Add Records”, “Table Update Records”, “Table Update Fields”

0x26+0x10

“Table Query”

Общая или частная

Обязательная

Дополнительная

Поиск табличных записей на основе определенных критериев

0хЕ1/Нет

“Beep ON/OFF”

Частная

Обязательная

Дополнительная

Включение/выключение звукового сигнала радиочастотной метки

0x8Е

“Delete Writeable Data”

Частная

Обязательная

Дополнительная

Удаление всех перезаписываемых данных радиочастотной метки

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

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

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

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 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 – Формат ответа на общую команду

Иденти-
фикатор протокола

Статус радиоча-
стотной метки

Длина пакета

Иденти-
фикатор сеанса

Идентифи-
катор изготови-
теля
радиочас-
тотной метки

Серийный номер радиочас-
тотной метки

Код команды

Данные

Код CRC

0x40

2 байта

1 байт

2 байта

2 байта

4 байта

1 байт

N байтов

2 байта

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

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

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

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

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

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

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

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

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

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

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

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

Иденти-
фикатор протокола

Статус радиоча-
стотной метки

Длина пакета

Иденти-
фикатор сеанса

Идентифи-
катор изготови-
теля
радиочас-
тотной метки

Серийный номер радиочас-
тотной метки

Код команды

Данные ответа*

Код CRC

0x40

2 байта

1 байт

2 байта

2 байта

4 байта

1 байт

N байтов

2 байта

* Это поле зависит от команды, для некоторых команд оно отсутствует.

В соответствии с таблицей 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 – Коды ошибок

Код ошибки

Наименование ошибки и описание

0x01

“Invalid Command Code” (недействительный код команды)

0x02

“Invalid Command Parameter” (недействительный параметр команды)

0x03

“Optional Command not Supported” (дополнительная команда не поддерживается)

0x04

“Not Found”(объект не найден)

0x06

“Can’t Create Object” (невозможно создать объект)

0x08

“Authorization Failure” (отказ авторизации)

0x09

“Object is Read-Only” (объект только для чтения)

0х0А

“Operation Failed” (сбой операции)

0x3f

“Implementation Dependent” (ошибка для данной версии)

0x40

“Stale Token” (недействительный маркер)

0x41

“Boundary Exceeded” (переполнение)

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

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

Код ошибки

Субкод

Данные параметров ошибки

Данные изготовителя

1 байт

1 байт

N байтов

М байтов

Таким образом, согласно таблице 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”

Код ошибки

0x01

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

6.2.6.3.2 Ошибка “”Invalid Command Parameter”

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

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

Код ошибки

Субкод

Смещение параметра

0x02

1 байт

1 байт

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

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

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

Таблица 11 – Субкоды ошибки “Invalid Command Parameter”

Субкод

Наименование разновидности ошибки (субошибки)

Описание

0x01

“Parameter Out of Range”

Значение параметра недействительно

0x02

“Too Few Parameters”

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

0x03

“Too Many Parameters”

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

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

6.2.6.3.3 Ошибка “Optional Command not Supported”

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

Таблица 12 – Сообщение об ошибке “Optional Command not Supported”

Код ошибки

0x03

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

6.2.6.3.4 Ошибка “Not Found”

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

Таблица 13 – Сообщение об ошибке “Not Found”

Код ошибки

Субкод

0x04

1 байт

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

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

Таблица 14 – Субкоды ошибки “Not Found”

Субкод

Наименование разновидности ошибки (субошибки)

Описание

0x01

“Table Does Not Exist”

Нет таблицы с данным идентификатором

0x02

“Record Does Not Exist”

Записей меньше указанного числа

0x03

“Field Does Not Exist”

Полей меньше указанного числа

6.2.6.3.5 Ошибка “Can’t Create Object”

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

Таблица 15 – Сообщение об ошибке “Can’t Create Object”

Код ошибки

Субкод

0x06

1 байт

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

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

Таблица 16 – Субкоды ошибки “Can’t Create Object”

Субкод

Наименование разновидности ошибки (субошибки)

Описание

0x02

“Table Already Exists”

Создаваемая таблица уже существует

0x03

“Out of Memory”

Памяти радиочастотной метки недостаточно для создания таблицы

0x04

“Table ID Reserved”

Данный идентификатор таблицы зарезервирован и не может быть использован

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

6.2.6.3.6 Ошибка “Authorization Failure”

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

Таблица 17 – Сообщение при ошибке “Authorization Failure”

Код ошибки

0x08

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

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

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

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

Код ошибки

0x09

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

6.2.6.3.8 Ошибка “Operation Failed”

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

Таблица 19 – Сообщение при ошибке “Operation Failed”

Код ошибки

Субкод

0х0А

1 байт

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

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

Таблица 20 – Субкоды ошибки “Operation Failed”

Субкод

Наименование разновидности ошибки (субошибки)

Описание

0x01

“Write Failure”

Операция записи в память проведена со сбоем

0x02

“Erase Failure”

Операция удаления записей из памяти проведена со сбоем

0x03

“Memory Consistency”

Обнаружено разрушение памяти

0x04

“Other Failure”

Операция выполнена со сбоем по другой причине

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

6.2.6.3.9 Ошибка “Implementation Dependent”

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

Таблица 21 – Сообщение при ошибке “Implementation Dependent”

Код ошибки

Субкод

0x3F

1 байт

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

6.2.6.3.10 Ошибка “Stale Token”

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

Таблица 22 – Сообщение об ошибке “Stale Token”

Код ошибки

0x40

Данный код ошибки генерируется в том случае, если маркер запроса (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”

Код ошибки

Субкод

0x41

1 байт

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

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

Таблица 24 – Субкоды ошибки “Boundary Exceeded”

Субкод

Наименование разновидности ошибки (субошибки)

Описание

0x01

“Table Full”

Данная таблица уже заполнена

0x02

“Record Does Not Exist”

Запись пока не добавлена

0x03

“Fragment Overrun”

Запись произведена не полностью

0x04

“Field Does Not Exist”

Данное поле не существует

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

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

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

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

Бит

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

Поле режима

Сигнал предупре-
ждения
(alarm)

Ре-
зерв

Ре-
зерв

Подтвер-
ждение: 1=NACK
0=АСК

Ре-
зерв

Ре-
зерв

Тип радиочас-
тотной метки

Резерв

Резерв

Серви-
сный бит

Примечание – Зарезервированные биты имеют значение “0”.

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

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

Таблица 26 – Формат поля режима (Mode field)
_______________

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

Поле режима

Код формата режима (биты 15-12)

Общая команда

0000

Частная команда

0010

бит сигнала предупреждения (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”

Код команды

Размер окна

Максимальная длина пакета

Код типа UDB

0x1F

2 байта

1 байт

1 байт

В соответствии с таблицей 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

Общая длина блока UDB

Запрошенное смещение

Данные блока UDB

0x1F

1 байт

2 байта

2 байта

N байтов

Все запрашиваемые командой данные блока 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

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

N байтов

Идентификатор типа элемента UDB (см. таблицу 30)

N (длина данных в байтах)

Байты данных

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

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

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

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

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

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

Идентификатор типа элемента блока UDB (1 байт)

Описание

Примечание

0х00-0х0А

“Reserved”

Эти элементы зарезервированы для будущих элементов данных

0x10

“Routing Code”

Маршрутный код, как определено в настоящем стандарте

0x11

“User ID”

Идентификатор пользователя, как определено в настоящем стандарте

0x12

“Optional Command List”

Список кодов дополнительных команд, поддерживаемых данной меткой

0x13

“Memory Size”

Общий и доступный объем памяти данной метки

0x14

“Table Query Size”

Общее число элементов команды “Table Query”, поддерживаемое меткой

0x15

“Table Query Results”

Результаты выполненной команды “Table Query”

0x16

“Hardware Fault Status”

Число перезагрузок оборудования, число перезагрузок сторожевого таймера (устройства самоконтроля), карта битов отказов оборудования (включая флаг разряда батареи) для представления дополнительной информации при установке “сервисного” бита в слове статуса метки

0x17-0x7F

“Reserved”

Эти элементы зарезервированы для будущих элементов данных

0x80-0xFE

“Future extension”

Зарезервировано для использования в будущем

0xFF

“Application Extension”

Расширение для конкретного применения

Уточненное название типа элемента блока UDB – “Application Extension” вместо названия “Application Element”, приведенного в оригинале ИСО/МЭК 18000-7:2009.

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

Таблица 31 – Формат элемента “Routing Code” блока UDB

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

N байтов

0x10

N

Данные маршрутного кода

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

Таблица 32 – Формат элемента “User ID” блока UDB

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

N байтов

0x11

N

Данные пользовательского идентификатора

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

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

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

N байтов

0x12

N

N однобайтовых значений кодов команд

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

Таблица 34 – Формат элемента “Memory Size” блока UDB

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

12 байт

4 байта

4 байта

4 байта

0x13

0х0С

Память для чтения/записи

Общая табличная память

Доступная табличная память

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

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

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

1 байт

0x14

0x01

Число поддерживаемых элементов команды “Table Query”

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

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

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

7 байт

1 байт

2 байта

2 байта

2 байта

0x15

0x07

Статус поиска

Идентификатор таблицы

Число совпадений записей

Номер первого совпадения записи

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

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

Значение поля “Статус поиска”

Описание

0x00

Операция “Table Query” успешно завершена

0x01

Метка не выполнила поиск, так как не получила полную последовательность пакетов команды “Table Query” или получившая команду метка имеет недействительный результат предыдущих запросов

0x02

Метка получила полную последовательность пакетов команды “Table Query”, но не может выполнить поиск (например, неверен идентификатор таблицы радиочастотной метки или значение идентификатора последовательности больше максимального значения, поддерживаемого меткой)

0x03

Частичные результаты поиска. Операция “Table Query” начата, но не завершена. Число совпадений записей и номер первого совпадения записи показывают частичные результаты поиска

0x04-0xFF

Зарезервировано

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

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

Идентификатор типа элемента блока UDB

Длина

Данные

1 байт

1 байт

3 байта

0x16

0x03

1 байт

1 байт

1 байт

Показания счетчика перезагрузок оборудования

Показания счетчика перезагрузок сторожевого таймера (встроенного программного обеспечения самоконтроля)

Битовая карта отказов оборудования

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

Бит 7

Бит 6

Бит 5

Бит 4

Бит 3

Бит 2

Бит 1

Бит 0

Резерв

Резерв

Резерв

Резерв

Резерв

Резерв

Дефект памяти

Разряд батареи

В соответствии с таблицей 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

Типы блока UDB

Описание

Элементы блока UDB, включенные в данный тип блока UDB

0x00

Передаваемые данные (Transit Data)

Элемент “Routing Code” (0x10), элемент “User ID” (0x11) и любые другие элементы блока UDB, определяемые применением

0x01

Системные данные (Capability Data)

Элемент “Optional Command List” (0x12), элемент “Memory Size” (0x13), элемент “Table Query Size” (0x14) и любые другие элементы блока UDB, определяемые применением

0x02

Результаты поиска (Query Results)

Элемент “Table Query Results” (0x15) и любые другие элементы блока UDB, определяемые применением

0x03

Данные об отказе оборудования (Hardware Fault Data)

Элемент “Hardware Fault Status” (0x16) и любые другие элементы блока UDB, определяемые применением

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

Таблица 41 – Формат элемента “Application Extension” блока UDB

Идентификатор элемента “Application Extension”

Длина элемента “Application Extension”

Элемент TLD с идентификатором применения

Элементы TLD применения

1 байт

1 байт

N байтов

М байтов

0xFF

(N+M) байтов

Элемент TLD, содержащий тип и значение идентификатора применения

Один или более элементов TLD, определяемых применением

В соответствии с таблицей 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 – Типы идентификатора применения

Код типа элемента TLD с идентификатором применения

Значение элемента TLD с идентификатором применения

0x00

“Manufacturer ID” – идентификатором применения является шестнадцатибитовый идентификатор изготовителя радиочастотной метки, присваиваемый органом регистрации в соответствии с ИСО/МЭК 15963

0x01

“Routing Code” – идентификатором применения является маршрутный код данных радиочастотной метки, как определено в ИСО 17363

0x02-0xFF

Зарезервировано

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

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

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

6.3.2 Команда “Sleep”

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

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

Код команды

0x15

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

6.3.3 Команда “Sleep All But”

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

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

Код команды

Идентификатор изготовителя радиочастотной метки

Серийный номер радиочастотной метки

0x16

2 байта

4 байта

Команда “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 – Команды, выполнение которых зависит от установки защиты паролем

Код команды

Название команды

Описание

0x93

“User ID”

Запись идентификатора пользователя (от 1 до 60 байтов)

0x89

“Routing Code”

Запись маршрутного кода

0хЕ0

“Write Memory”

Запись пользовательской памяти

0x95*

“Set Password”*

Установка пароля (4 байта)

0x97*

“Set Password Protect Mode”*

Включение или выключение режима защиты паролем

0x26

“Table Create”

Создание таблицы базы данных

0x26

“Table Add Records”

Подготовка добавления новых записей в существующую таблицу

0x26

“Table Update Records”

Подготовка изменения записей таблицы

0x26

“Table Update Fields”

Подготовка изменения полей записи таблицы

0x26

“Table Delete Records”

Удаление существующей записи из существующей таблицы базы данных

0x26

“Table Write Fragment”

Запись блока данных в таблицу после команд “Table Add Records”, “Table Update Records”, “Table Update Fields”

0x8Е

“Delete Writeable Data”

Удаление всех перезаписываемых данных радиочастотной метки

* Для этих команд режим защиты паролем всегда включен.

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

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

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

Код команды

Пароль

0x95

4 байта

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

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

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

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

Код команды

0x95

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

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

Код ошибки

Ошибка

Причина

0x02

“Invalid Command Parameter”

Параметр пароля в команде не определен или имеет неправильную длину

0x08

“Authorization Failure”

Команде “Set Password” не предшествовала команда “Unlock”

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

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

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

Код команды

Флаг защиты

0x97

1 байт

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

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

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

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

Код команды

0x97

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Параметр флага защиты в команде не определен или имеет неправильную длину

0x08

“Authorization Failure”

Команде “Set Password Protect Mode” не предшествовала команда “Unlock”

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

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

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

Код команды

Пароль

0x96

4 байта

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

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

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

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

Код команды

0x96

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

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

Код ошибки

Ошибка

Причина

0x02

“Invalid Command Parameter”

Параметр пароля в команде отсутствует или имеет неправильную длину

0x08

“Authorization Failure”

Неправильное значение пароля

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

6.3.5.1 Команда “User ID”

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

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

Код команды

0x13

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

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

Код команды

Длина пользовательского идентификатора

Значение пользовательского идентификатора

0x13

1 байт

N байтов

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

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

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

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

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

Код команды

Длина пользовательского идентификатора

Значение пользовательского идентификатора

0x93

1 байт

N байтов

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

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

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

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

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

Код команды

0x93

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

“NEN” (“Netherlands Normalisatie-instituut”)

Адрес:

Postbus 5059,

2600 GB Delft,

The Netherlands

Факс: +31 15 26 90 242

E-mail: RA-ISO15459@nen.nl

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Длина параметра пользовательского идентификатора не совпадает с указанным параметром длины пользовательского идентификатора, или представлено неверное число байтов параметра, или значение параметра длины пользовательского идентификатора больше максимально допустимого (“60”)

0x08

“Authorization Failure”

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

0х0А

“Operation Failed”

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

6.3.5.2 Команда “Routing Code”

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

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

Код команды

0x09

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

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

Код команды

Длина маршрутного кода

Значение маршрутного кода

0x09

1 байт

N байтов

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

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

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

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

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

Код команды

Длина маршрутного кода

Значение маршрутного кода

0x89

1 байт

N байтов

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

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

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

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

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

Код команды

0x89

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Значение параметра длины маршрутного кода в команде превышает максимально допустимое значение (“50”), или длина параметра маршрутного кода не соответствует параметру длины маршрутного кода, или передано неверное число байтов параметра

0x08

“Authorization Failure”

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

0х0А

“Operation Failed”

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

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

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

6.3.6.1 Команда “Firmware Version”

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

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

Код команды

0х0С

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

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

Код команды

Версия МПО радиочастотной метки

0х0С

4 байта

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

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

6.3.6.2 Команда “Model Number”

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

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

Код команды

0x0Е

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

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

Код команды

Номер модели радиочастотной метки

0x0Е

2 байта

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

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

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

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

6.3.7.1 Команда “Write Memory”

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

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

Код команды

Число байтов данных

Начальный адрес

Данные

0хЕ0

1 байт

3 байта

N байтов

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

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

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

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

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

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

Код команды

0хЕ0

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

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

0x08

“Authorization Failure”

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

0х0А

“Operation Failed”

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

6.3.7.2 Команда “Read Memory”

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

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

Код команды

Число считываемых байтов

Начальный адрес

0x60

1 байт

3 байта

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

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

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

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

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

Код команды

Число реально считанных байтов

Данные

0x60

1 байт

N байтов

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

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

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

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

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

0х0А

“Operation Failed”

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

6.3.8 Команда “Delete Writeable Data”

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

Таблица 75 – Формат команды “Delete Writeable Data”

Код команды

0x8Е

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

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

Код команды

0x8Е

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

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

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

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

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

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

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

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

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

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

Код ошибки

Наименование ошибки

Причина

0x08

“Authorization Failure”

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

0х0А

“Operation Failed”

Внутренний сбой при удалении данных радиочастотной метки

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”

Код команды

Код типа блока UDB

Смещение в блоке UDB

Максимальная длина пакета

0x70

1 байт

2 байта

1 байт

В соответствии с таблицей 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”

Код команды

Код типа блока UDB

Общая длина блока UDB

Запрошенное смещение

Блок UDB

0x70

1 байт

2 байта

2 байта

N байтов

В соответствии с таблицей 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”

Код ошибки

Ошибка

Причина

0x02

“Invalid Command Parameter”

Параметр смещения в блоке UDB превышает общую длину запрошенного блока UDB, или значение максимальной длины пакета меньше “21”, или неверно задано число байтов параметров

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

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

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

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

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

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

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

Область значений идентификатора таблицы

Тип таблицы

0x0000-0x7FFF

Определен ИСО

0x8000-0xBFFF

Специальный

0xC000-0xFFFF

Изготовителя/продавца

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

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

Значения идентификаторов таблиц в диапазоне “изготовителя/продавца” зарезервированы для реализации продавцом дополнительных функций и расширений в процессе изготовления и сбыта. В этой области значений чтение и запись таблиц базы данных должно производиться с помощью стандартных команд для базы данных, но таблицы могут иметь дополнительные свойства и функции. Значения идентификаторов таблиц в диапазоне “изготовителя/продавца” доступны для использования исключительно по усмотрению изготовителя/продавца, отсутствуют требования публикации назначения или используемого интерфейса внутри этой области идентификаторов таблиц. Данные, собираемые с помощью команды “Collection with UDB”, содержат данные из блока данных изготовителя (блока MDB) и из универсального блока данных (блока UDB). Данные блока MDB должны храниться в таблицах базы данных со значениями идентификаторов таблиц из диапазона “изготовителя/продавца”, как описано в 6.3.10.
_______________
. Данные блока 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 – Структура маркера

Длина маркера N

Данные маркера

Значение N в битах – 7-4 (Значение N=0-15)

Четыре младших бита байта длины маркера, затем N байтов

Команды работы с таблицами делятся на команды чтения и записи. К командам чтения относятся команды “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”

Код команды

Субкод команды

Идентификатор таблицы

Максимальное число записей

Число полей

Длина каждого поля

0x26

0x01

2 байта

2 байта

1 байт

N байтов

В соответствии с таблицей 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”

Код команды

0x26

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

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

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

0x06

“Can’t Create Object”

Идентификатор таблицы уже использован для существующей таблицы, а команда не является повторной, или у радиочастотной метки не хватает памяти, или идентификатор таблицы равен “0x0000”;

следующие субкоды уточняют вид ошибки:

“0x02” – объект уже существует;

“0x03” – не хватает памяти;

“0x04” – значение зарезервировано

0x08

“Authorization Failure”

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

0х0А

“Operation Failed”

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

6.3.10.2 Команда “Table Add Records”

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

Таблица 86 – Формат команды “Table Add Records”

Код команды

Субкод команды

Идентификатор таблицы

Идентификатор последовательности

Количество записей

0x26

0x02

2 байта

1 байт

2 байта

В соответствии с таблицей 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”

Код команды

Маркер

0x26

N байтов

В соответствии с таблицей 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”

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

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

0x04

“Not Found”

Отсутствует таблица базы данных с указанным идентификатором

0x08

“Authorization Failure”

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

0x09

“Object is Read-Only”

Значение идентификатора таблицы равно “0x0000”, что означает таблица “Query Results Table” – только для чтения

0x41

“Boundary Exceeded”

Таблица настолько заполнена, что не может вместить добавляемые записи

6.3.10.3 Команда “Table Update Records”

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

Таблица 89 – Формат команды “Table Update Records”

Код команды

Субкод команды

Идентификатор таблицы

Номер начальной записи

Количество записей

0x26

0x03

2 байта

2 байта

2 байта

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

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

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

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

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

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

Код команды

Маркер

0x26

N байтов

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

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

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Параметр числа записей равен нулю или указано неверное число байтов параметра

0x04

“Not Found”

Отсутствует в базе данных таблица с указанным идентификатором таблицы

0x08

“Authorization Failure”

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

0x09

“Object is Read-Only”

Значение идентификатора таблицы равно “0x0000”, что означает, что таблица “Query Results Table” – только для чтения

0x41

“Boundary Exceeded”

Сумма номера начальной записи и числа записей больше общего числа записей в таблице

6.3.10.4 Команда “Table Update Fields”

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

Таблица 92 – Формат команды “Table Update Fields”

Код команды

Субкод команды

Идентификатор таблицы

Номер записи

Номер начального поля

Число полей

0x26

0x04

2 байта

2 байта

1 байт

1 байт

В соответствии с таблицей 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”

Код команды

Маркер

0x26

N байтов

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

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Параметр числа полей равен нулю или указано неверное число байтов параметра

0x04

“Not Found”

Отсутствует таблица базы данных с указанным идентификатором таблицы

0x08

“Authorization Failure”

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

0x09

“Object is Read-Only”

Значение идентификатора таблицы равно “0x0000”, это означает, что таблица “Query Results Table” – только для чтения

0x41

“Boundary Exceeded”

Номер записи больше или равен общему числу записей в таблице или сумма номера начального поля и числа полей в команде больше общего числа полей в таблице

6.3.10.5 Команда “Table Delete Record”

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

Таблица 95 – Формат команды “Table Delete Record”

Код команды

Субкод команды

Идентификатор таблицы

Идентификатор последовательности

Номер записи

0x26

0x05

2 байта

1 байт

2 байта

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

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

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

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

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

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

Код команды

0x26

Команда “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”

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

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

0x04

“Not Found”

Отсутствует таблица базы данных с указанным идентификатором таблицы

0x08

“Authorization Failure”

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

0x09

“Object is Read-Only”

Значение идентификатора таблицы равно “0x0000”, это означает, что таблица “Query Results Table” – только для чтения

0х0А

“Operation Failed”

База данных повреждена или невозможно выполнить удаление записи

0x41

“Boundary Exceeded”

Номер записи больше или равен общему числу записей в таблице

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

6.3.10.6 Команда “Table Get Data”

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

Таблица 98 – Формат команды “Table Get Data”

Код команды

Субкод команды

Идентификатор таблицы

Номер начальной записи

Номер начального поля

0x26

0x06

2 байта

2 байта

1 байт

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

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

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

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

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

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

Код команды

Маркер

0x26

N байтов

В соответствии с таблицей 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”

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Указано неверное число байтов в параметре

0x04

“Not Found”

Отсутствует таблица базы данных с указанным идентификатором таблицы; или значение идентификатора таблицы равно “0x0000”, а результаты поиска отсутствуют по причинам: не было поиска, результат поиска сделан недействительным подачей команды записи в запрошенную таблицу в которой проводился поиск или начат новый поиск

0x41

“Boundary Exceeded”

Номер начальной записи больше или равен общему числу записей в таблице или номер начального поля больше или равен числу полей в таблице

6.3.10.7 Команда “Table Get Properties”

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

Таблица 101 – Формат команды “Table Get Properties”

Код команды

Субкод команды

Идентификатор таблицы

0x26

0x07

2 байта

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

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

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

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

Код команды

Общее число записей

Максимальное число записей

Зарезервировано

0x26

2 байта

2 байта

1 байт

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

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

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

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Указано неверное число байтов в параметре

0x04

“Not Found”

Отсутствует таблица базы данных с указанным идентификатором

6.3.10.8 Команда “Table Read Fragment”

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

Таблица 104 – Формат команды “Table Read Fragment”

Код команды

Субкод команды

Маркер запроса

Длина данных запроса

0x26

0x08

N байтов

1 байт

В соответствии с таблицей 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”

Код команды

Маркер ответа

Реальная длина считываемых данных

Данные

0x26

N байтов

1 байт

М байтов

В соответствии с таблицей 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”

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Радиочастотная метка определила маркер запроса как неверный (определяется применением радиочастотной метки), или запрошенная длина данных равна нулю, или указано неверное число байтов в параметре, или маркер запроса равен “0х00”

0x40

“Stale Token”

Маркер запроса правильно сформирован и не равен “0x00”, но недействителен, так как таблица, к которой относится маркер запроса, модифицирована. Эта модификация включает в себя выполнение команд, связанных с идентификатором таблицы, указанным со следующими командами: “Table Add Records”, “Table Update Records”, “Table Update Field” и “Table Delete Record”

0х0А

“Operation Failed”

База данных повреждена или невозможно выполнить операцию считывания

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

6.3.10.9 Команда “Table Write Fragment”

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

Таблица 107 – Формат команды “Table Write Fraqment”

Код команды

Субкод команды

Маркер запроса

Длина данных

Данные

0x26

0x09

N байтов

1 байт

N байтов

В соответствии с таблицей 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”

Код команды

Маркер ответа

0x26

N байтов

В соответствии с таблицей 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”

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Радиочастотная метка определила маркер запроса как неверный (как определено применением радиочастотной метки), или параметр длины данных запроса равен нулю, или длина параметра данных не соответствует длине данных, или указано неверное число байтов в параметре, или маркер запроса равен “0x00”

0x08

“Authorization Failure”

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

0х0А

“Operation Failed”

База данных повреждена или невозможно выполнить операцию записи

0x40

“Stale Token”

Маркер запроса правильно сформирован и не равен “0x00”, но недействителен, так как таблица, к которой относится маркер запроса, модифицирована. Эта модификация включает в себя выполнение команд, связанных с идентификатором таблицы, указанным со следующими командами: “Table Add Records”, “Table Update Records”, “Table Update Fields” и “Table Delete Record”

0x41

“Boundary Exceeded”

Длина данных для этого запроса больше указанной в первоначальной команде “Table Add Records”, “Table Update Records” или “Table Update Record Fields”

6.3.10.10 Команда “Table Query”

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

Таблица 110 – Формат команды “Table Query”

Код команды

Субкод операции

Иденти-
фикатор таблицы

Идентификатор последовате-
льности

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

Логический оператор

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

Номер поля

Оператор отношения

Длина данных сравнения

Данные сравнения

0x26

0x10

2 байта

1 байт

1 байт

1 байт

1 байт

1 байт

N байтов

В соответствии с таблицей 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”

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Идентификатор последовательности больше максимального номера оператора поиска, поддерживаемого радиочастотной меткой, или идентификатор последовательности не такой, каким должен быть, или меньше параметра предыдущей команды “Table Query” и логический оператор – не CLEAR;

или идентификатор таблицы не такой, как для предыдущей команды и логический оператор – не CLEAR;

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

0x04

“Not Found”

Отсутствует таблица базы данных с указанным идентификатором таблицы

0x41

“Boundary Exceeded”

Номер поля больше или равен числу полей в таблице

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”

Код команды

0x26

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

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

Код команды

Число совпадающих записей

Индекс первой совпадающей записи

0x26

2 байта

2 байта

В соответствии с таблицей 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”.
_______________
). Радиочастотная метка ответит сообщением со своим серийным номером и элементом результатов поиска “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”

Код команды

Включение/выключение сигнала

0хЕ1

1 байт

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

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

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

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

Код команды

0хЕ1

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

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

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

Код ошибки

Наименование ошибки

Причина

0x02

“Invalid Command Parameter”

Параметр команды отсутствует, имеет неправильную длину или недопустимое значение

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 – Параметры линии связи УСО с радиочастотной меткой

Ссылка

Параметр

Значение

УСО:1

Номинальный рабочий диапазон частот

433,92 МГц

УСО:1а

Рабочая частота по умолчанию

433,92 МГц

УСО:1b

Рабочие частотные каналы

Не применяется

УСО:1с

Отклонение от центральной частоты передатчика УСО

±30 ppm

УСО:1d

Частота перестройки

Не применяется

УСО:1е

Последовательность частотных скачков

Не применяется

УСО:2

Максимальная ширина полосы частотной модуляции передатчика УСО по уровню минус 10 дБ

200 кГц (передача)

УСО:2а

Минимальная полоса пропускания приемника радиочастотной метки по уровню минус 3 дБ

300 кГц

УСО:3

Максимальная эквивалентная изотропно-излучаемая мощность (EIRP) передатчика УСО

В соответствии с местными нормами регулирования

УСО:4

Паразитные излучения передатчика УСО

УСО:4а

Паразитные внутриполосные излучения передатчика УСО

Не применяется

УСО:4b

Паразитные внеполосные излучения передатчика УСО

В соответствии с нормами страны применения для данного типа систем

УСО:5

Спектральная маска передатчика УСО

Не применяется

УСО:6

Синхронизация

УСО:6а

Время переключения УСО с передачи на прием

1 мс

УСО:6b

Время переключения УСО с приема на передачу

1 мс

УСО:6с

Время задержки при включении УСО

1 мс

УСО:6d

Время запаздывания при выключении УСО

1 мс

УСО:7

Модуляция

Частотная манипуляция (FSK)

УСО:7а

Расширяющая последовательность

Не применяется в этом режиме

УСО:7b

Скорость передачи единичных элементов сигнала

Не применяется в этом режиме

УСО:7с

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

Не применяется в этом режиме

УСО:7d

Глубина модуляции

Не применяется в этом режиме

УСО:7е

Коэффициент заполнения

Не применяется в этом режиме

УCO:7f

Девиация частоты передатчика УСО

±50 кГц ±10 кГц

УСО:8

Кодирование данных

Манчестерский код: длительность одного бита: 36 мкс; логическая единица: перепад от низкого уровня сигнала (18 мкс) к высокому (18 мкс); логический ноль: перепад от высокого уровня сигнала (18 мкс) к низкому (18 мкс)

УСО:9

Номинальная скорость передачи данных УСО

27778 Кбит/с

УСО:9а

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

27778 Кбит/с ±2%

УСО:10

Точность модуляции сигнала передатчика

Не применяется в этом режиме

УСО:11

Преамбула

УСО:11а

Длина преамбулы

21 бит

УСО:11b

Форма сигнала преамбулы

Меандр (см. УСО:11с)

УСО:11с

Последовательность синхронизации битов

20 периодов [высокий уровень (30 мкс), низкий уровень (30 мкс)], за ними 1 период [высокий уровень (54 мкс), низкий уровень (54 мкс)]

УСО:11d

Последовательность синхронизации фрейма

20 периодов [высокий уровень (30 мкс), низкий уровень (30 мкс)], за ними 1 период [высокий уровень (54 мкс), низкий уровень (54 мкс)]

УСО:12

Скремблирование

Не применяется в этом режиме

УСО:13

Порядок передачи битов

Байты: младший бит передается первым; данные: старший байт передается первым

УСО:14

Процесс “Wake Up”

Используется

УСО:15

Поляризация

Не определена

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

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

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

Ссылка

Параметр

Значение

Метка:1

Номинальный рабочий диапазон частот

433,92 МГц

Метка:1а

Рабочая частота по умолчанию

433,92 МГц

Метка:1b

Рабочие каналы

Не применяется в этом режиме

Метка:1с

Отклонение от центральной частоты передатчика метки

±30 ppm

Метка:1d

Частота перестройки

Не применяется в этом режиме

Метка:1е

Последовательность частотных скачков

Не применяется в этом режиме

Метка:2

Максимальная ширина полосы частотной модуляции передатчика метки по уровню -10 дБ

200 кГц (передача)

Метка:2а

Минимальная полоса пропускания приемника УСО по уровню -3 дБ

300 кГц

Метка:3

Максимальная эквивалентная изотропно-излучаемая мощность (EIRP) передатчика метки

Приблизительно 1 мВт в соответствии с нормами страны применения

Метка:4

Паразитные излучения передатчика метки

Метка:4а

Паразитные внутриполосные излучения передатчика метки

Не применяется в этом режиме

Метка:4b

Паразитные внеполосные излучения передатчика метки

В соответствии с нормами страны применения для данного типа систем

Метка:5

Спектральная маска передатчика метки

Не применяется в этом режиме

Метка:6

Синхронизация

Метка:6а

Время перехода от передачи к приему

1 мс

Метка:6b

Время перехода от приема к передаче

1 мс

Метка:6с

Время установления сигнала передатчика

1 мс

Метка:6d

Время спада сигнала передатчика

1 мс

Метка:7

Модуляция

Частотная манипуляция (FSK)

Метка:7а

Расширяющая последовательность

Не применяется в этом режиме

Метка:7b

Скорость передачи единичных элементов сигнала

Не применяется в этом режиме

Метка:7с

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

Не применяется в этом режиме

Метка:7d

Отношение уровней или длительности сигнала во включенном и выключенном состояниях

Не применяется в этом режиме

Метка:7е

Частота поднесущей

Не применяется в этом режиме

Метка:7f

Отклонение частоты поднесущей

Не применяется в этом режиме

Метка:7g

Модуляция поднесущей

Не применяется в этом режиме

Метка:7h

Коэффициент заполнения

Не применяется в этом режиме

Метка:7i

Девиация частоты передатчика

±50 кГц ±10 кГц (девиация частотной манипуляции)

Метка:8

Кодирование данных

Манчестерский код: длительность одного бита: 36 мкс; логическая единица: перепад от низкого уровня сигнала (18 мкс) к высокому (18 мкс); логический ноль: перепад от высокого уровня сигнала (18 мкс) к низкому (18 мкс)

Метка:9

Номинальная скорость передачи данных

27778 Кбит/с

Метка:9а

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

27778 Кбит/с ±5%

Метка:10

Точность модуляции сигнала передатчика

Не применяется в этом режиме

Метка:11

Преамбула

Метка:11а

Длина преамбулы

21 бит

Метка:11b

Форма сигнала преамбулы

Меандр (см. “Метка:11с”)

Метка:11с

Последовательность синхронизации битов

20 периодов [высокий уровень (30 мкс), низкий уровень (30 мкс)], за ними 1 период [высокий уровень (42 мкс), низкий уровень (54 мкс)]

Метка:11d

Последовательность синхронизации фрейма

20 периодов [высокий уровень (30 мкс), низкий уровень (30 мкс)], за ними 1 период [высокий уровень (42 мкс), низкий уровень (54 мкс)]

Метка:12

Скремблирование

Не применяется в этом режиме

Метка:13

Порядок передачи битов и данных

Байты: младший бит передается первым; данные: старший байт передается первым

Метка:14

(Параметр зарезервирован)

Метка:15

Поляризация

Не определена

Метка:16

Минимальная ширина полосы частот приемника метки

200 кГц

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

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

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

Ссылка

Параметр

Значение

Протокол:1

Инициатор связи

УСО (протокол связи “УСО говорит первым”, “RTF”)

Протокол:2

Возможность адресации памяти радиочастотной метки

Да

Протокол:3

Уникальный идентификатор (UID) радиочастотной метки

Да

Протокол:3а

Длина идентификатора UID

48 бит

Протокол:3b

Формат идентификатора UID

Бинарный

Протокол:4

Объем считывания

От 1 до 255 байтов

Протокол:5

Объем записи

От 1 до 255 байтов

Протокол:6

Время передачи данных при чтении

25 мс

Протокол: 7

Время передачи данных при записи

30 мс

Протокол:8

Обнаружение ошибок

Код CRC-16 по CCITT

Протокол:9

Исправление ошибок

Нет

Протокол:10

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

Код команды – 8 бит

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

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

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

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

Ссылка

Параметр

Описание

А:1

Тип

Вероятностный

А:2

Линейность (для N радиочастотных меток)

Вероятностная: 0,065N с для 13000

A:3

Емкость инвентаризации радиочастотных меток

Вероятностная: 3000 радиочастотных меток

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

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

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

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

Идентификатор протокола

Стандарты

0x31

ИСО/МЭК 18000-7, версия 0

0x40

ИСО/МЭК 18000-7, версия 1

0x80

ИСО 18185 eSeal (электронные пломбировочные устройства – электронные ПУ)

0хС0

ИСО 17363 (радиочастотные метки для грузовых контейнеров)

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

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

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

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

Радиочастотные метки должны также поддерживать определенные в данных технических требованиях команды “Sleep”.

Рисунок А.1 – Запрос и ответ по конкретному идентификатору протокола

Рисунок А.1 – Запрос и ответ по конкретному идентификатору протокола

Рисунок А.2 – Совместимость радиочастотных меток для различных применений

Рисунок А.2 – Совместимость радиочастотных меток для различных применений

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов и документов национальным стандартам Российской Федерации

Приложение ДА
(справочное)

Таблица ДА.1

Обозначение ссылочного международного стандарта, документа

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

ИСО/МЭК 8859-1

*

ИСО/МЭК 15459 (все части)

IDT

ГОСТ Р ИСО/МЭК 15459 (части 1-6) “Автоматическая идентификация. Идентификаторы уникальные международные”

ИСО/МЭК 15963

IDT

ГОСТ Р ИСО/МЭК 15963-2011 “Информационные технологии. Радиочастотная идентификация для управления предметами. Уникальная идентификация радиочастотных меток”

ИСО 17363

IDT

ГОСТ Р ИСО 17363-2010 “Применение радиочастотной идентификации (RFID) в цепи поставок. Контейнеры грузовые”

ИСО/МЭК ТО 18047-7

*

ИСО 18185

*

ИСО/МЭК 19762-1

IDT

ГОСТ Р ИСО/МЭК 19762-1-2011 “Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь. Часть 1. Общие термины в области АИСД”

ИСО/МЭК 19762-3

IDT

ГОСТ Р ИСО/МЭК 19762-3-2011 “Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь. Часть 3. Радиочастотная идентификация (РЧИ)”

МЭК 60601-1-2:2001

MOD

ГОСТ Р 50267.0.2-2005 (МЭК 60601-1-2:2001) “Изделия медицинские электрические. Часть 1-2. Общие требования безопасности. Электромагнитная совместимость. Требования и методы испытаний”

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

Примечание – В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов:

– IDT – идентичные стандарты;

– MOD – модифицированные стандарты.

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

Приложение ДБ
(справочное)

Перевод на русский язык наименований команд по ИСО/МЭК 18000-7 приведен в таблице ДБ.1.

Таблица ДБ.1 – Перевод на русский язык наименований команд по ИСО/МЭК 18000-7

Международное наименование команды по ИСО/МЭК 18000-7

Перевод на русский язык

“Веер ON/OFF”

Установка/снятие звукового сигнала

“Collection with UDB”

Сбор данных с универсальным блоком данных

“Delete Writeable Data”

Удаление всех перезаписываемых данных радиочастотной метки

“Firmware Version”

Считывание номера версии микропрограммного обеспечения

“Model Number”

Считывание номера модели радиочастотной метки

“Query Results”

Запрос результатов

“Read Memory”

Считывание памяти

“Read Universal Data Block”

Считывание универсального блока данных

“Routing Code”

Считывание/запись маршрутного кода

“Set Password Protect Mode”

Включение/выключение режима защиты паролем

“Set Password”

Установка пароля

“Sleep”

Переход в спящее состояние

“Sleep All But”

Перевод в спящее состояние всех радиочастотных меток, кроме одной

“Table Add Records”

Подготовка добавления новых записей в существующую таблицу

“Table Create”

Создание таблицы базы данных

“Table Delete Records”

Удаление записи из таблицы

“Table Get Properties”

Получение данных о формате таблицы

“Table Query”

Запрос/поиск таблицы

“Table Query Size”

Размер последовательности элементов запроса, поддерживаемых радиочастотной меткой

“Table Update Fields”

Подготовка изменения полей записи таблицы

“Table Update Records”

Подготовка изменения записей таблицы

“Table Write Fragment”

Запись блока данных в таблицу

“Unlock”

Разблокирование

“User ID”

Запись/считывание пользовательского идентификатора

“Write Memory”

Запись пользовательской памяти

Перевод на русский язык наименований сигналов по ИСО/МЭК 18000-7 приведен в таблице ДБ.2.

Таблица ДБ.2 – Перевод на русский язык наименований сигналов по ИСО/МЭК 18000-7

Международное наименование сигнала по ИСО/МЭК 18000-7

Перевод на русский язык

“Co-Header”

Подзаголовок сигнала пробуждения

“Wake Up”

Пробуждение

“Wake Up Header”

Заголовок сигнала пробуждения

Перевод на русский язык наименований ошибок по ИСО/МЭК 18000-7 приведен в таблице ДБ.3.

Таблица ДБ.3 – Перевод на русский язык наименований ошибок по ИСО/МЭК 18000-7

Международное наименование ошибки по ИСО/МЭК 18000-7

Перевод на русский язык

“Authorization Failure”

Отказ авторизации

“Boundary Exceeded”

Переполнение

“Can’t Create Object”

Невозможно создать объект

“Implementation Dependent”

Ошибка для данной версии

“Invalid Command Code”

Недействительный код команды

“Invalid Command Parameter”

Недействительный параметр команды

“Not Found”

Объект не найден

“Object is Read-Only”

Объект только для чтения

“Operation Failed”

Сбой операции

“Optional Command not Supported”

Дополнительная команда не поддерживается

“Stale Token”

Недействительный маркер

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

Таблица ДБ.4 – Перевод на русский язык наименований основных физических параметров канала связи между УСО и радиочастотной меткой по ИСО/МЭК 18000-7

Международное наименование параметра по ИСО/МЭК 18000-7

Перевод на русский язык

“Bit Rate Accuracy”

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

“Bit Sync Sequence”

Последовательность синхронизации битов

“Bit Transmission Order”

Порядок передачи битов

“Chip Rate”

Скорость передачи единичных элементов сигнала

“Chip Rate Accuracy”

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

“Data Coding”

Кодирование данных

“Default Operating Frequency”

Рабочая частота по умолчанию

“Duty Cycle”

Коэффициент заполнения

“Frame Sync Sequence”

Последовательность синхронизации фрейма

“Frequency Hop Rate”

Скорость скачкообразного изменения частоты

“Frequency Hop Sequence”

Последовательность скачкообразного изменения частоты

“Interrogator/Tag Transmit Centre Frequency”

Отклонение от центральной частоты передатчика УСО/радиочастотной метки

“Interrogator/Tag Transmit Frequency Deviation”

Девиация частоты передатчика УСО/радиочастотной метки

“Interrogator/Tag Transmit Modulation Accuracy”

Точность модуляции сигнала передатчика УСО/радиочастотной метки

“Interrogator/Tag Transmit Power Down Ramp”

Время запаздывания при выключении УСО/радиочастотной метки

“Interrogator/Tag Transmit Power On Ramp”

Время задержки при включении УСО/радиочастотной метки

“Maximum Interrogator/Tag Transmit Modulation Bandwidth @ -10 dBc”

Максимальная ширина полосы частотной модуляции передатчика УСО/радиочастотной метки по уровню минус 10 дБ

“Minimum Interrogator/Tag Receiver Bandwidth @ -3 dB”

Минимальная полоса пропускания приемника УСО/радиочастотной метки по уровню минус 3 дБ

“Minimum Tag Receiver Bandwidth”

Минимальная ширина полосы частот приемника радиочастотной метки

“Modulation Index (interrogator to tag link)”

Глубина модуляции (линия связи УСО с радиочастотной меткой)

“Modulation”

Модуляция

“Nominal Interrogator/Tag Data Bit Rate”

Номинальная скорость передачи данных УСО/радиочастотной метки

“Nominal Operating Frequency Range”

Номинальный рабочий диапазон частот

“On-Off Ratio”

Отношение уровней или длительности сигнала во включенном и выключенном состояниях

“Operating Channels”

Рабочие частотные каналы

“Polarization”

Поляризация

“Preamble Length”

Длина преамбулы

“Preamble Waveform”

Форма сигнала преамбулы

“Preamble”

Преамбула

“Receive to Transmit Turn Around Time”

Время переключения с приема на передачу

“Scrambling”

Скремблирование

“Spreading Sequence”

Расширяющая последовательность

“Sub-Carrier Frequency (tag to interrogator link)”

Частота поднесущей (линия связи радиочастотной метки с УСО)

“Sub-Carrier Frequency Accuracy (tag to interrogator link)”

Отклонение частоты поднесущей (линия связи радиочастотной метки с УСО)

“Sub-Carrier Modulation (tag to interrogator link)”

Модуляция поднесущей (линия связи радиочастотной метки с УСО)

“Timing”

Синхронизация

“Transmit Maximum EIRP”

Максимальная эквивалентная изотропно-излучаемая мощность (EIRP) передатчика УСО/радиочастотной метки

“Transmit Spurious Emissions, In-Band”

Паразитные внутриполосные излучения передатчика УСО/радиочастотной метки

“Transmit Spurious Emissions, Out of Band”

Паразитные внеполосные излучения передатчика УСО/радиочастотной метки

“Transmit Spurious Emissions”

Паразитные излучения передатчика УСО/радиочастотной метки

“Transmit to Receive Turn Around Time”

Время переключения с передачи на прием

“Transmitter Spectrum Mask”

Спектральная маска передатчика УСО/радиочастотной метки

“Wake-Up Process (interrogator to tag link)”

Процесс пробуждения (линия связи УСО с радиочастотной меткой)

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

Таблица ДБ.5 – Перевод на русский язык наименований основных физических параметров протокола связи по ИСО/МЭК 18000-7

Международное наименование параметра по ИСО/МЭК 18000-7

Перевод на русский язык

“Command structure and extensibility”

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

“Error correction”

Исправление ошибок

“Error detection”

Обнаружение ошибок

“Read size”

Объем считывания

“Read Transaction Time”

Время передачи данных при чтении

“Reader-Talks-First (RTF)”

УСО говорит первым (протокол связи “RTF”

“Tag addressing capability”

Возможность адресации памяти радиочастотной метки

“Tag UID”

Уникальный идентификатор (UID) радиочастотной метки

“UID Format”

Формат идентификатора UID

“UID Length”

Длина идентификатора UID

“Who talks first”

Инициатор связи (“кто говорит первым”)

“Write Size”

Объем записи

“Write Transaction Time”

Время передачи данных при записи

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

В настоящем стандарте использовано устаревшее название идентификатора радиочастотной метки – UID. Согласно действующему стандарту ИСО/МЭК 15963:2009 идентификатор радиочастотной метки называется TID (от английского “Tag Identifier”).

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

Таблица ДБ.6 – Перевод на русский язык наименований основных параметров антиколлизионного алгоритма по ИСО/МЭК 18000-7

Международное наименование параметра по ИСО/МЭК 18000-7

Перевод на русский язык

“Linearity (for N tags)”

Линейность (для N радиочастотных меток)

“Type”

Тип

“Tag inventory capacity”

Емкость инвентаризации радиочастотных меток

Библиография

[1]

ISO/IEC Directives, Part 2

Rules for the structure and drafting of International Standards

[2]

ISO/IEC 18000-1

Information technology – Radio frequency identification for item management – Part 1: Reference architecture and definition of parameters to be standardized

[3]

ISO/IEC TR 18001

Information technology – Radio frequency identification for item management – Application requirements profiles

[4]

ISO/IEC 18046

Information technology – Automatic identification and data capture techniques – Radio frequency identification device performance test methods

[5]

ERC REC 70-03

Relating to the Use of Short Range Devices (SRD), Annex 1, Band e; European Radio-communications Committee (ERC)

[6]

US Code of Federal
Regulations (CFR)

Title 47 – Telecommunication, Chapter I – Federal Communications Commission, Part 15 – Radio frequency devices, Section 15.231 – “Periodic operation in the band 40.66-40.70 MHz and above 70 MHz”; U.S. Federal Communications Commission

[7]

ISO 17363

Supply chain applications of RFID – Freight containers

[8]

ISO 18185-1

Freight containers – Electronic seals – Part 1: Communication protocol

[9]

ISO 18185-2

Freight containers – Electronic seals – Part 2: Application requirements

[10]

ISO 18185-3

Freight containers – Electronic seals – Part 3: Environmental characteristics

[11]

ISO 18185-4

Freight containers – Electronic seals – Part 4: Data protection

[12]

ISO 18185-5

Freight containers – Electronic seals – Part 5: Physical layer

[13]

ITU-T Recommendation
V.41 (11/88)

Code-independent error control system

[14]

IEEE 1451.7

Standard for a Smart Transducer Interface for Sensors and Actuators – Transducers to Radio Frequency Identification (RFID) Systems Communication Protocols and Transducer Electronic Data Sheet Formats

____________________________________________________________________________________
УДК 681.5.015:621.3:006:354 ОКС 35.040 П85

Ключевые слова: радиочастотная идентификация для управления предметами, активный радиоинтерфейс, диапазон частот, 433 МГц
____________________________________________________________________________________

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2014

Николай Иванов

Эксперт по стандартизации и метрологии! Разрешительная и нормативная документация.

Оцените автора
Все-ГОСТЫ РУ
Добавить комментарий