Электронная библиотека » Маниш Бхуптани » » онлайн чтение - страница 5


  • Текст добавлен: 10 июня 2022, 12:41


Автор книги: Маниш Бхуптани


Жанр: Зарубежная компьютерная литература, Зарубежная литература


сообщить о неприемлемом содержимом

Текущая страница: 5 (всего у книги 21 страниц) [доступный отрывок для чтения: 6 страниц]

Шрифт:
- 100% +
Антенна

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

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


Рис. 3.5. Типичные пассивные радиометки с антеннами (фотографии любезно предоставлены Texas Instruments Inc. и Alien Technology Corporation (крайняя метка слева))


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


[Закрыть]
. Скажем, в приложении для слежения за паллетами считыватель может быть связан с сетью антенн, образующих (для точной и надежной работы погрузочной платформы на складе) вполне определенную зону детектирования объектов, такую, как портал или въездные ворота (рис. 3.6).


Рис. 3.6. RFID-считыватель и антенны для построения портала (фотография любезно предоставлена Symbol Technologies, Inc.)


Ограничения в канале связи «метка – считыватель сигнала»

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

• жидкостей, таких как вода,

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

• высокой влажности воздуха,

• экстремальных температур – как крайне высоких, так и чересчур низких,

• двигателей, моторов машин,

• беспроводных устройств, например мобильных телефонов и КПК,

• беспроводных компьютерных сетей и сетей связи,

• радиотелефонов.

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

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

Хост-компьютер

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

Программные компоненты

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

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

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

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

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

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


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

Программное обеспечение 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-системах, компаниям действительно необходимо пересмотреть архитектуру бизнес-моделей и приложений.

Сеть EPCglobal

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

Электронный код продукта EPC

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

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

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

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

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


Такая 96-разрядная спецификация EPC-кода[17]17
  Консорциум EPCglobal выпустил и 64-битовый формат EPC-кода.


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


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

Система идентификации

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

Межплатформенное программное обеспечение EPC

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

Сервис Object Name Service (ONS)

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

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

Сервисы EPC Information Services (EPCIS)

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


[Закрыть]
.

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

Заключение

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

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


Страницы книги >> Предыдущая | 1 2 3 4 5 6 | Следующая
  • 0 Оценок: 0

Правообладателям!

Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.

Читателям!

Оплатили, но не знаете что делать дальше?


Популярные книги за неделю


Рекомендации