Конкретные возможности и функциональность программных компонентов RFID-систем сильно варьируют в зависимости от приложения и его потребностей. Эти компоненты систем можно отнести к одной из следующих категорий:

• программное обеспечение RFID-системы,

• межплатформенное ПО (middleware),

• хост-приложение.

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

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

^{Рис. 3.7. Программные компоненты RFID и их взаимозависимость}

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

Чтение-запись

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

Борьба с коллизиями

Программное обеспечение, созданное для борьбы с коллизиями («столкновением», конфликтом данных), используется, если в поле зрения считывателя находится целый ряд меток, распознавание и отслеживание которых должны вестись одновременно. Подобное характерно для большинства приложений по управлению цепочками поставок. К примеру, в приложении по управлению запасами, которое инсталлировано на складе, единственный считыватель RFID может «видеть» сотни и даже тысячи объектов с радиометками в поле радиусом до метра и более. Единственная паллета швейных изделий, снабженных такими метками, может содержать не менее ста коробок, в каждой из которых находятся десятки предметов одежды. Борьба с коллизиями требует такого взаимодействия меток и считывателей, которое минимизирует риск одновременного ответа от нескольких меток. Нередко используемый для этого алгоритм может быть очень простым и заключаться в выборе каждой меткой случайного времени ожидания перед откликом на запрос считывателя.

Обнаружение и коррекция ошибок

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

Шифрование, авторизация и подтверждение подлинности (обеспечение безопасности)

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

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

Межплатформенное ПО (middleware) для RFID содержит набор программных компонентов, «наводящих мосты» между элементами системы RFID (т. е. метками и считывателями) и программным хост-приложением. При этом оно выполняет две важнейшие функции:

• ведет мониторинг функционирования и состояния считывателя,

• управляет потоком данных и особой инфраструктурой RFID (метками и считывателями).

Эти функции связаны между собой и часто предполагают работу с общими данными. Тем не менее они нацелены на разные потребности приложений и обладают различными характеристиками. Ниже мы опишем каждую из этих функций отдельно. Заметим, что большинство производителей межплатформенного программного обеспечения RFID предлагают продукты, где обе функции представлены в едином пакете. Однако, как и в случае с любым многофункциональным пакетом, каждый производитель реализует функции межплатформенного ПО с разной степенью проработки. Ваш выбор в пользу решения определенного поставщика должен учитывать потребности вашего приложения. Ряд конкретных рекомендаций, призванных помочь вам сделать свой выбор, мы дадим в главе 8.

Мониторинг

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

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

Управление

В общем виде функция управления включает в себя кодирование, сбор, обработку, фильтрацию и накопление данных, передаваемых с метки на считыватель и обратно в целях интеграции с хост-приложением. Особое значение эта функция приобретает в среде, где считыватель может получать «лавинные» или постоянные потоки данных от меток (например, при управлении цепочками поставок). Данные меток должны подвергаться очистке и фильтрации, в частности для устранения дублирования. При этом, в соответствии с предварительно определенными правилами сбора данных, могут выдаваться предупреждения.

Другая важная функция, выполняемая на этом этапе, – нормализация данных. В отсутствие стандартов форматы данных, которые использует считыватель, и протоколы коммуникации с хост-приложением, как правило, являются корпоративными, частными. Работая в среде, компоненты которой получены от различных поставщиков, межплатформенное ПО для RFID ответственно за перевод форматов данных различных устройств в единый, нормализованный формат, упрощающий интеграцию на уровне хост-приложения.

Хост-приложение через считыватель и межплатформенное ПО получает обработанные и нормализованные данные меток. Обычно функции хост-приложения выполняет уже существующая на предприятии программная система, к примеру, для управления запасами или складом. В зависимости от степени усовершенствования межплатформенного ПО и собственных возможностей хост-приложение может даже не нуждаться в сведениях об источнике данных, которые получает. Так, приложение управления запасами может с успехом отслеживать все продукты на полках розничных магазинов, «не зная» о том, как происходит ввод данных. До внедрения RFID их могли вводить вручную или через систему штрихового кодирования. Если в приложение встроен вполне определенный интерфейсный протокол ввода данных, то межплатформенное ПО должно лишь обработать и отформатировать данные, поступающие от меток, а также воспользоваться протоколом хост-приложения, чтобы переслать на него информацию.

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

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

Однако независимо от того, оказалась ли существующая система способной обрабатывать RFID-данные или возникла необходимость в разработке нового интерфейса или нового продукта, следует помнить еще об одной существенной проблеме. Во многих случаях RFID дает компании совершенно новые данные, поэтому маловероятно, что она обладает бизнес-моделью, способной в полной мере эффективно использовать эти данные. Так, в типичном решении для управления цепочками поставок на базе RFID товары опознаются по электронным кодам продуктов – EPC (Electronic Product Code), представляющим собой расширенную форму используемых в системах штрихового кодирования универсальных кодов продуктов (Universal Product Code – UPC) и позволяющим кодировать данные о товарах более детально, чем UPC. В имеющихся бизнес-моделях цепочек поставок и приложениях, первоначально созданных для работы с UPC-данными, теперь открыт доступ к новым расширенным EPC-данным, которые эти бизнес-модели и приложения могут и должны использовать эффективно. В разделе «Интеграция цепочек поставок товаров» главы 1 мы назвали эту проблему однозначным распознаванием. Поэтому для обретения возможности в полной мере использовать преимущества работы с новыми, дополнительными данными, полученными в RFID-системах, компаниям действительно необходимо пересмотреть архитектуру бизнес-моделей и приложений.

Возможность взаимодействия – насущная потребность комплексных приложений цепочек поставок, где товары могут перемещаться между десятками различных торговых контрагентов и предприятий, каждое из которых, возможно, обладает уникальной инфраструктурой RFID с уникальными потребностями системы. В связи с этим необходимость иметь общий инструмент форматирования, обработки данных и обмена ими, помогающий взаимодействовать разнородным уникальнымсистемам, становится очевидной. На решение этой проблемы нацелены усилия организации EPCglobal, занятой выработкой одноименных стандартов. Ключевые компоненты создания RFID-систем, соответствующих стандартам EPCglobal, мы опишем ниже. Все вместе эти компоненты носят название EPCglobal Network. В главе 4 мы обсудим важнейшие стандарты EPCglobal и прочих организаций, которые уже были приняты или находятся на стадии рассмотрения. Стандарты EPCglobal ускоренно развиваются, поэтому за информацией о новых достижениях и событиях в деле стандартизации мы советуем вам обращаться на сайт EPCglobal (www.epcglobalinc.org), а также требовать последние системные обновления у ваших поставщиков.

Электронный код продукта (EPC) – это схема нумерации, позволяющая присвоить уникальный идентификатор любому физическому объекту. EPC можно считать очередным поколением универсальных кодов продуктов (UPC), которые наносятся на большинство товаров в настоящее время. EPC – это способ назначить собственный идентификатор для любого изделия и тем самым сделать его однозначно распознаваемым. Нынешний формат данных EPC Type I, предоставляющий такую возможность, содержит следующие поля (рис. 3.8):

• заголовок (обозначает номер версии EPC),

• номер владельца (указывает на предприятие, которое использует данный EPC-номер),

• класс объекта (показывает класс или категорию продукта, аналогичен единице складского учета (Stock Keeping Unit – SKU),

• серийный номер (содержит уникальный код экземпляра маркируемого товара).

Такая 96-разрядная спецификация EPC-кода[17] позволяет однозначно распознавать 268 млн компаний, каждая из которых может иметь 16 млн классов объектов – по 68 млрд серийных номеров в каждом.

^{Рис. 3.8. Формат нумерации электронных кодов продуктов EPC}

Систему идентификации EPCglobal образуют метки и считыватели. EPC-код хранится на EPC-метке, которую опрашивает EPC-считыватель. Именно в этой области на текущий момент сосредоточена большая часть работ над стандартами EPCglobal. Сегодня уже имеется ряд стандартов с описаниями формата и функций меток, а также связи «метка – считыватель» для меток различных типов (подробности см. в главе 4). Конечная цель – создание и продвижение стандартов, предлагающих общие правила, которые позволят меткам и считывателям производства любой компании функционировать в едином ключе, не испытывая проблем в процессе коммуникации.

В среде обслуживания цепочек поставок, выдающей на считыватель практически постоянный поток EPC-кодов, задача управления данными приобретает особое значение. За управление потоком EPC-данных между существующими в компании считывателями и корпоративными приложениями отвечает межплатформенное программное обеспечение (EPC Middleware, известное также под своим прежним именем Savant). Его функции схожи с описанными ранее функциями межплатформенного программного обеспечения RFID и включают в себя сбор, обработку, фильтрацию и агрегирование данных.

Сервис Object Name Service (ONS), обеспечивающий отслеживание продукта, находит соответствие между его EPC-кодом и информацией о нем. Когда межплатформенное ПО (EPC Middleware) получает EPC-данные, оно может запросить ONS-сервер, на котором хранится более подробная информация о продуктах.

Модель этого сервиса повторяет реализованную в Интернете систему доменных имен (Domain Name System – DNS), которую отличают высокая масштабируемость, производительность и надежность. В глобальной сети вы можете передать DNS-серверу строку URL и получить связанный с ней IP-адрес. Масштабы использования RFID, по прогнозам, потребуют распознавания триллионов изделий тысяч производителей с использованием для этого общественной сетевой инфраструктуры, поэтому в разработке ONS и были задействованы принципы организации DNS-сервиса.

Компонент EPCIS определяет сервисы и интерфейсы, необходимые для упрощения обмена данными между приложениями торговых партнеров во всей цепочке товарных поставок. Ключевая функция EPCIS – поддержка центрального репозитария EPC-данных, который совместно используется и обновляется партнерами по сделкам в цепочке поставок по всему миру. При полноценной реализации и принятии бизнесом EPCIS предоставит инфраструктуру, необходимую для ускорения подлинной комплексной интеграции цепочек поставок товаров[18].

Дополнительные технические детали архитектуры EPCglobal Network описаны в приложении Б, в котором помещено официальное фирменное описание – «Архитектура EPC Network корпорации Sun» («The Sun EPC Network Architecture»). В этом документе описана архитектура типичной системы такого рода, основанной на спецификациях EPCglobal и продемонстрирован способ объединения нескольких ключевых компонентов EPCglobal с целью формирования фундамента крупномасштабного приложения для управления цепочками поставок.