IMES – Universidade Municipal de São Caetano do Sul
Estudo sobre redes EPC e Tecnologia RFID
Diego Augusto Valentim , Número 60 , Matrícula 53140-0 , Turma 4AN
Eduardo José Pin , Número 70 , Matrícula 53222-6 , Turma 4AN
São
Caetano do Sul
2004
IMES – Universidade Municipal de São Caetano do Sul
Estudo sobre redes EPC e Tecnologia RFID
Diego Augusto Valentim , Número 60 , Matrícula 53140-0 , Turma 4AN
Eduardo José Pin , Número 70 , Matrícula 53222-6 , Turma 4AN
Trabalho de
Conclusão de Curso de Ciências da Computação do IMES – Universidade Municipal
de São Caetano do Sul , sob orientação do Professor
Mário Eugênio Longato
PIN, Eduardo
José / PIN , Eduardo / JOSÉ , Eduardo VALENTIM .
Diego Augusto / VALENTIM , Diego / AUGUSTO , Diego Estudo sobre redes EPC e Tecnologia RFID São
Caetano do Sul – SP Brasil; 2004 192p. Trabalho
de Conclusão de Curso (TCC), do Curso de Ciência da Computação da
Universidade IMES. Informática. 1.Introdução 2.Fundamentos sobre Eletromagnetismo ,
Rádio-Frequência e Transmissão RFID 3.Propriedades e
Características de Componentes RFID 4.Legislação
, Padronização Vigente e Classes em RFID 5.Especificações e
Características da Codificação EPC
6.Savant 7. Physical Markup
Language (PML) 8.Object Name Service (ONS) 9.Projeto de Implementação de Redes EPC IMES –
UNIVERSIDADE MUNICIPAL DE SÂO CAETANO DO SUL.Ciências da Computação
À Marisa Valle , minha mãe
, por toda a paciência nesses 4 anos de graduação; e , acima de tudo, por tudo que me ensinou e por tudo que ainda
irá me ensinar.
(Diego A. Valentim)
Ao meu pai , que sempre acreditou na minha
capacidade; e à minha mãe , que se dedicou e me apoiou durante toda a minha vida.
(Eduardo J. Pin)
Resumo
Abstract
Índice
Objetivos............................................................................................................................... 13
Capítulo 1 – Introdução ........................................................................................................ 15
Capítulo 2 – Fundamentos sobre Eletromagnetismo , Rádio-Frequência e Transmissão RFID................. 25
2.1 Radiação Eletromagnética e Faixas Eletromagnéticas............................................. 25
2.2 Ondas de Rádio................................................................................................... 28
2.3 Transmissão e Recepção de Ondas de Rádio........................................................ 29
2.4 Alcance de um Sistema de Comunicação de Rádio................................................ 30
2.5 Antenas e Comprimento de Ondas........................................................................ 33
2.6 Operação Básica em um Sistema RFID................................................................. 34
2.7 Considerações sobre alcance em Sistemas RFID................................................... 36
2.8 Lendo múltiplos tags............................................................................................. 37
2.9 Utilizando múltiplos leitores................................................................................... 38
Capítulo 3 – Propriedades e Características de Componentes RFID....................................... 40
3.1 Tags RFID........................................................................................................... 40
3.1.1 Modelos de Construção de Tags............................................................ 40
3.1.2 Classes de Tags..................................................................................... 43
3.1.3 Tags Passivos e Ativos .......................................................................... 46
3.1.4 Métodos de Comunicação entre tags e leitores........................................ 49
3.1.5 Tags LF e HF........................................................................................ 50
3.1.6 Tags UHF............................................................................................. 51
3.2 Leitores RFID...................................................................................................... 52
3.2.1 Características Gerais sobre leitores........................................................ 52
3.2.2 Considerações sobre antenas de leitores................................................. 54
Capítulo 4 – Legislação , Padronização Vigente e Classes em RFID....................................... 57
4.1 Legislação Referente à Utilização de RFID........................................................... 57
4.1.1 O papel da Legislação e da Regulação de Faixas.................................... 57
4.1.2 Conceituação de Legislação em Sistemas RFID...................................... 57
4.1.3 Legislações Específicas nas Diversas Faixas Eletromagnéticas................. 58
4.1.4 Operações Fora da Faixa Alocada......................................................... 60
4.2 Padronizações e Normas Estabelecidas para RFID.............................................. 60
4.2.1 O papel dos Padrões na Indústria RFID................................................. 60
4.2.2 Normas e Padrões Estabelecidos para RFID.......................................... 61
4.3 Classes RFID....................................................................................................... 66
4.3.1 A Estrutura de Classes........................................................................... 66
4.3.2 Princípios de Modularidade de Plataforma e Estados Padrões................ 68
Capítulo 5 – Especificações e Características da Codificação EPC......................................... 70
5.1 Introdução à Especificação e Codificação EPC..................................................... 70
5.2 Conceitos sobre Identidade .................................................................................. 72
5.2.1 Camada de Identidade Pura:Tipos Genéricos.......................................... 74
5.2.2 Camada de Identidade Pura:Sistemas de Identificação EAN.UCC.......... 75
5.3 Codificações em nível de bits para Tags EPC........................................................ 77
5.3.1 Headers................................................................................................. 77
5.3.2 Convenções de Notação........................................................................ 80
5.3.3 General Identifier (GID-96).................................................................... 81
5.3.4 Serialized Global Trade Item Number (SGTIN)...................................... 82
5.3.4.1 SGTIN-64................................................................................ 83
5.3.4.2 SGTIN-96................................................................................ 85
5.3.5 Serial Shipping Container Code (SSCC)................................................ 87
5.3.5.1 SSCC-64.................................................................................. 87
5.3.5.2 SSCC-96.................................................................................. 89
5.3.6 Serialized Global Location Number (SGLN)........................................... 91
5.3.6.1 SGLN-64.................................................................................. 91
5.3.6.2 SGLN-96.................................................................................. 93
5.3.7 Global Returnable Asset Identifier (GRAI).............................................. 95
5.3.7.1 GRAI-64................................................................................... 95
5.3.7.2 GRAI-96................................................................................... 97
5.3.8 Global Individual Asset Identifier (GIAI)................................................. 99
5.3.8.1 GIAI-64................................................................................... 99
5.3.8.2 GIAI-96................................................................................. 101
5.4 Representação URI............................................................................................ 103
5.4.1 Formas URI para Identidades Puras..................................................... 103
5.4.2 Formas URI para Tags EPC................................................................. 106
Capítulo 6 – Savant.............................................................................................................. 108
6.1 Arquitetura de Sistema das Redes EPC............................................................... 108
6.2 Savant - Visão Geral........................................................................................... 111
6.3 Interface do Leitor.............................................................................................. 114
6.4 Módulos de Processamento................................................................................ 115
6.5 Interface de Aplicações....................................................................................... 118
6.5.1 Estruturação em Camadas.................................................................... 118
6.5.2 Canais de Mensagens........................................................................... 120
6.5.3 Estrutura dos Comandos...................................................................... 121
6.5.4 Mensagens de Requisição em Canais de Controle................................. 122
6.5.5 Mensagens de Resposta em Canais de Controle................................... 123
6.6 Módulos de Processamento Padrões................................................................... 123
6.6.1 Módulo de Processamento Padrão autoid.core..................................... 124
6.6.1.1 Mensagem GetSavantID........................................................... 124
6.6.1.2 Mensagem GetCapabilities....................................................... 125
6.6.1.3 Mensagem Shutdown............................................................... 126
6.6.1.4 Mensagem ResetAll.................................................................. 126
6.6.2 Módulo de Processamento Padrão autoid.readerproxy......................... 127
6.6.2.1 Mensagem GetReaders............................................................ 127
6.6.2.2 Mensagem RunCommand......................................................... 128
6.7 Interface de Aplicações - Messaging / Transport Bindings (MTBs)...................... 129
6.7.1 MTB XML-RPC / HTTP..................................................................... 129
6.7.1.1 Requisições em Canais de Controle.......................................... 131
6.7.1.2 Respostas em Canais de Controle............................................. 131
6.7.1.3 Especificação de Mensagens : Módulo Core............................. 132
6.7.1.4 Especificação de Mensagens : Módulo ReaderProxy................. 134
6.7.2 MTB SOAP-RPC/http......................................................................... 136
6.7.2.1 Savant e Aplicações Comerciais como um nó SOAP................ 137
6.7.2.2 Mensagens AI.......................................................................... 137
6.7.2.3 Regras para Implementações SOAP......................................... 138
6.7.2.4 Especificação para Objetos-Alvo URI...................................... 139
6.7.2.5 Arquitetura de Esquemas AI..................................................... 141
6.7.2.6 Especificação de Mensagens do Módulo Core......................... 143
6.7.2.7 Especificação de Mensagens do Módulo ReaderProxy............. 145
Capítulo 7 – Physical Markup Language (PML)................................................................... 147
7.1 Descrição geral e cenários de uso........................................................................ 148
7.2 Características gerais da PML Core.................................................................... 149
7.3 Tipos de dados que poderão ser representados através da PML Core................. 151
7.4 Arquitetura do esquema PML Core.................................................................... 152
7.5 Estrutura de arquivos da PML Core................................................................... 155
7.5.1 Modelagem de Sensores na PML Core................................................ 156
7.6 Elementos da PML Core.................................................................................... 157
7.6.1 Elemento ID......................................................................................... 157
7.6.2 Elemento Sensor.................................................................................. 157
7.6.3 Elemento Observation.......................................................................... 159
7.6.4 Elemento Data...................................................................................... 160
7.6.5 Elemento Tag....................................................................................... 162
7.7 Esquemas XML............................................................................................................. 164
7.7.1 PMLCore.xsd...................................................................................... 164
7.7.2 Identifier.xsd........................................................................................ 169
Capítulo 8 – Object Name Service (ONS)........................................................................... 171
8.1 Conceitos gerais sobre o ONS............................................................................ 172
8.2 EPC e Consultas ao ONS.................................................................................. 174
8.2.1 Formato das Consultas DNS............................................................... 175
8.2.2 Formato dos Resultados...................................................................... 175
8.3 Exemplos de Consultas ...................................................................................... 177
8.3.1 Encontrando um arquivo WSDL para um produto................................. 178
8.3.2 Encontrando um Servidor PML para um produto.................................. 178
8.3.3 Encontrando uma pagina HTML que contenha informações sobre o produto................................................................................................................................ 179
8.3.4 Encontrando um gateway XML-RPC para interfaces WEB................. 179
Capítulo 9 – Projeto de Implementação de Redes EPC........................................................ 180
Conclusões.......................................................................................................................... 189
Bibliografia........................................................................................................................... 193
Objetivos
Este trabalho tem como objetivos principais descrever o funcionamento da tecnologia EPC(Electronic Product Code) através da utilização de RFID (Radio Frequency Identification) e também sugerir um cenário / topologia de implementação de uma aplicação real.
A tecnologia RFID
surgiu na década de 40 e é utilizada para transmitir dados de identificação de
objetos ou animais através de rádio freqüência. Por sua vez , a tecnologia EPC
surgiu há poucos anos e o seu funcionamento baseia-se nos padrões da tecnologia
RFID. A tecnologia EPC disponibiliza sistemas que tem a capacidade de
identificar , por exemplo , produtos em um supermercado através de um código
eletrônico que é transmitido através de RFID e captado por um Sistema de
Informação , que armazena e gerencia qualquer elemento que possuir um EPC dentro
de um determinado ambiente.Desta forma, o EPC permite a substituição da
tecnologia de código de barras, tanto nos pontos finais de venda dos produtos
quanto nas áreas de logística envolvidas.
Desta forma , este trabalho tem também como objetivo descrever e detalhar a relação e a interação entre essas duas tecnologias (RFID / EPC), mostrando suas capacidades , características , vantagens e limitações.
Uma característica interessante da tecnologia EPC , como já citado , é o próprio fato de ser muito recente . Desta forma , muitos aspectos de seu funcionamento e dos impactos de sua adoção ainda estão em discussão , para que se possa formar um padrão único e oficial , aplicável em um mercado globalizado e complexo como o que presenciamos atualmente. Contudo , essa tecnologia vem recebendo fortes investimentos , tanto de empresas privadas, quanto de universidades ; e há grandes perspectivas para sua utilização em larga escala em um futuro muito próximo.
A implementação do EPC depende, no entanto, de uma infra-estrutura completa que possa viabilizar operacionalmente o seu funcionamento; além de disponibilizar interfaces com ambientes externos e ferramentas de gerenciamento. A partir deste princípio, surge também o conceito das redes EPC. Uma rede EPC é o conjunto de todos os componentes necessários para sua utilização, sejam eles dispositivos físicos (componentes RFID, por exemplo), como também desportivos computacionais e sistêmicos. Desta forma, este trabalho detalhará também as especificações e funcionamentos previstos para estes componentes, para que a partir daí seja possível visualizar uma rede EPC como um Sistema de Informação, e que pode também integrar-se com outros Sistemas de Informação
Ao fim deste trabalho , esperamos que seja possível visualizar a utilização destas duas tecnologias (RFID e EPC) em conjunto e de forma clara ; e que se tenha parâmetros e embasamaneto para avaliar suas aplicações práticas, desde qual infra-estrutura é necessária ara implementá-las até os aspectos referentes às utilidades e vantagens das tecnologias em si.
|
Capítulo 1 |
Introdução |
Ao falarmos da tecnologia EPC , é interessante que voltemos um pouco no tempo para estudar o início e o desenvolvimento da tecnologia RFID , que está intrinsecamente ligada ao seu funcionamento.
Os fundamentos do funcionamento da tecnologia RFID estão diretamente relacionados com o eletromagnetismo.
Muitos cientistas resumem a criação do Universo com o fenômeno do Big Bang. Eles deduzem que as quatro forças fundamentais (gravidade , eletromagnetismo e a fraqueza e potência das forças nucleares) estavam unificadas . Contudo , a primeira forma do Universo foi a energia eletromagnética. Durante os primeiros segundos do Universo , prótons , neutrons e elétrons começaram sua formação quando então os photons (o elemento quântico da energia eletromagnética) colidiram-se convergindo energia em massa.O eletromagnetismo restante do Big Bang sobrevive hoje em segundo plano como um assobio em formato microondas.
Bilhões de anos se passaram até que se descobrisse como aproveitar a energia eletromagnética em transmissões via rádio e aí então aplicar esse conhecimento para o desenvolvimento do RFID.
Provavelmente os chineses foram os primeiros a observar e utilizar ondas magnéticas em forma de cargas no século I A.C. Os cientistas progrediram muito lentamente até o começo do século XVII. De 1600 à 1800 houve um grande aumento de observações e estudos sobre eletricidade , magnetismo e ótica , acompanhados pelo crescimento de bases matemáticas.Um dos primeiros pioneiros da eletricidade do século XVIII foi Benjamin Franklin.
O século XVIII foi marcado como o começo do entendimento fundamental da energia eletromagnética. Michael Faraday , um célebre estudioso experimentalista inglês , propôs em 1846 que tanto à luz quanto as ondas de rádio são parte de força eletromagnética. Em 1864 , James C. Maxwell , um físico escocês , publicou sua teoria sobre ondas eletromagnéticas e concluiu que a eletricidade e a energia magnética viajam em ondas transversais que se propagam em uma velocidade muito próxima a da luz. Depois, em 1887 , Heinrich R. Hertz , um físico alemão , confirmou a teoria eletromagnética de Maxwell , e então produziu e estudou ondas eletromagnéticas (ondas de rádio) , onde ele mostrava o quão longe as ondas transversais viajavam na velocidade da luz e como elas poderiam ser refletidas , refratadas e polarizadas como luz. Hertz é creditado como o primeiro a transmitir e receber ondas de rádio , e suas demonstrações foram seguidas rapidamente por Aleksandr Popov na Rússia.
Em 1896 , Gugliemo Marconi demonstrou com sucesso uma transmissão de rádio-telégrafo através do Oceano Atlântico , o que significou um marco histórico para a humanidade.
Em 1906 , Ernst W. Alexanderson demonstrou a primeira geração de rádio por ondas contínuas e também a transmissão de sinais de rádio. Esse fato acabou significando o começo da comunicação por rádio moderna , onde todos os aspectos das ondas de rádio foram controladas.
No começo do século 20 , aproximadamente 1922 , surge um novo marco : o nascimento do radar. O trabalho realizado sobre isso na Segunda Guerra Mundial foi um significativo desenvolvimento técnico realizado no Projeto Manhattan nos Laboratórios Científicos Los Alamos . Os radares enviavam ondas de rádio ao detectarem e localizarem um objeto por reflexão de ondas de rádio. Essa reflexão podia determinar a posição e a velocidade de um objeto. A importância do radar foi rapidamente compreendida pelos militares , e os primeiros desenvolvimentos ocorreram sob sigilo.
Sabendo-se que o RFID é a combinação da tecnologia de transmissão via rádio e dos radares , não é surpresa que a convergência dessas duas disciplinas derivadas do rádio e as idéias sobre o RFID ocorreram com o aparecimento e desenvolvimento do radar.
De qualquer forma , como ocorre com diversas tecnologias , não é possível estimar exatamente quando o RFID nasceu , tendo em vista que atividades paralelas ocorreram no seu surgimento , pelo próprio fato de cientistas estarem trabalhando e tendo idéias em paralelo até que se passasse a acumular conhecimentos e experiências.
Provavelmente , o primeiro trabalho explorando RFID foi um artigo de Harry Stockman , chamado “Communication by Means of Reflected Power”.Ele constatou que ainda haviam problemas básicos relacionados a comunicação baseadas em forças de reflexão, e que ainda haveria muito trabalho e estudo a fazer antes de se buscar aplicações úteis para o modelo.
Trinta anos se passaram antes da visão de Harry começar a dar frutos. Outros desenvolvimentos foram necessários : o transistor , os circuitos integrados , o microprocessador e o desenvolvimento de redes de comunicação , que mudaram o rumo da tecnologia e dos negócios.
A década de 50 foi uma época de exploração das técnicas de RFID que deram continuidade aos desenvolvimentos técnicos em rádio e radar dos anos 30 e 40.Muitas tecnologias relacionadas ao RFID foram exploradas , como os sistemas de transponders de longa distância conhecidos como “identification , friend or foe” (IFF) para aviões.Outros desenvolvimentos da década de 50 incluem trabalhos como “Application of the microwave homodyne” de F.L. Vernon e “Radio Transmission systems with modulatable passive Responder” , de D.B. Harris. Com isso , o desenvolvimento do RFID estava tomando força e sendo cada vez mais difundido.
A década de 60 foi o prelúdio da explosão do RFID que ocorreu nos anos 70. R.F. Harrington estudou a teoria eletromagnética relatada em seus artigos. Os inventores estavam ocupados com as invenções relacionadas ao RFID e também abordavam seus estudos em diversos artigos.
As atividades comerciais começaram ainda na década de 60. Duas empresas foram fundadas no final da década : Sensormatic e Checkpoint. Essas companhias desenvolveram um equipamento conhecido como EAS , para conter roubos. Esse tipo de sistema utilizava tags de “1 bit” – apenas a presença or ausência do tag podia ser detectada , mas mesmo assim eles demonstraram serem muito eficientes em sua utilização.Esse tipo de sistema utilizava tanto microondas quanto tecnologia indutiva. O EAS é reconhecido como a primeira e mais comercialmente difundida aplicação de RFID.
Na década de 70 , desenvolvedores , inventores , acadêmicos , empresas , instituições e o próprio governo trabalharam ativamente em RFID , e notáveis avanços foram realizados em laboratórios e instituições científicas , como por exemplo os laboratórios Los Alamos , a Universidade NorthWest e a Fundação do Instituto de Microondas , na Suécia.
Muitas companhias também desenvolveram tecnologias RFID , como a Raytheon , com sua “Raytag” em 1973. A RCA desenvolveu um Sistema Eletrônico de Identificação em 1975 e também um específico para veículos em 1977. A Fairchild desenvolveu um transponder passivo baseado em microondas em 1978.
Alguns órgãos governamentais testaram sistemas da General Eletric , Philips e Gleynare. Os resultados foram favoráveis , porém o primeiro sucesso comercial baseado em RFID não aconteceu imediatamente.
A década de 70 foi caracterizada inicialmente pelo trabalho de desenvolvimento da tecnologia. As primeiras aplicações tinham como objetivos o rastreamento de animais e veículos e a automação industrial. Exemplos de aplicação para animais foram os sistemas via microondas do Laboratórios Los Alamos e os sistemas indutivos na Europa , onde o interesse pela aplicação em animais foi muito grande. Nesta época , empresas como Alfa Laval , Nedap e outras estavam desenvolvendo muitos trabalhos sobre RFID.
Esforços referentes à sistemas de transporte incluem trabalhos nos Laboratórios Los Alamos e na Associação IBTTA , além da Administração Federal Rodoviária dos EUA. Estas últimas duas Associações realizaram uma conferência em 1973 onde concluíram que não havia interesse nacional em desenvolver um padrão para identificação eletrônica de veículos.Esta foi uma importante decisão desde que permitiu que uma grande variedade de sistemas fossem desenvolvidos , o que em certo aspecto foi bom , já que tratava-se dos primeiros passos da tecnologia.
Nesta época novas companhias começaram a aparecer , como a Identronix , que surgiu de uma divisão dos Laboratórios Los Alamos ; e também a Amtech (mais tarde adquirida pela Intermec) , já na década de 80. A partir de então , o número de companhias e instituições que trabalhavam com RFID começaram a se multiplicar , sinalizando positivamente que o potencial da tecnologia era muito grande.
A década de 80 tornou-se uma época de muitas implementações da tecnologia RFID, com diversas aplicações sendo desenvolvidas em diversas partes do mundo . O grande interesse do EUA foi referente a transportes , acesso pessoal e para uso animal. Na Europa , o grande interesse foi para sistemas de curta distância para animais , indústrias e aplicações comerciais , como pedágios rodoviários na Itália , França , Espanha , Portugal e Noruega.
Na América , a Associação de Estradas Americana e o Programa Cooperativo de Transportes de Carga iniciaram esforços para a utilização da tecnologia. Testes de RFID para postos de pedágio foram feitos por muitos anos e as primeiras aplicações comerciais iniciaram-se na Europa em 1987 na Noruega , e foram seguidas rapidamente nos EUA pela Dallas North Turnpike em 1989.Também nesta época a autoridade Portuária de Nova York e New Jersey começaram operações comerciais de RFID para ônibus que passavam pelo Túnel Lincoln . O RFID foi encontrando novos caminhos nestas aplicações e novas soluções foram aparecendo a cada dia.
A década de 90 teve um significado muito forte para o RFID , já que teve um enorme desenvolvimento na área de pedágios eletrônicos nos EUA. Importantes desenvolvimentos incluem também as diversas inovações neste aspecto. Em 1991, foi ativada a primeira rodovia do mundo equipada com sistemas eletrônicos de pedágio , em Oklahoma , onde os veículos podiam passar por pontos eletrônicos de coleta de pedágio , mesmo em velocidades altas. A primeira combinação de pedágios eletrônicos e gerenciamento de tráfego ocorreu com um sistema instalado em Houston em 1992. Nesta época houve também um sistema instalado no Kansas que possuía leitores que podiam operar com tags de Oklahoma , seu estado vizinho do Sul. O sistema Georgia 400 também seguiu esses passos , atualizando seus equipamentos com leitores que podiam se comunicar com os novos tags “Title 21” assim como com as tags já existentes. De fato , estas duas aplicações foram as primeiras implementações de suporte a multi-protocolo nas aplicações de pedágios eletrônicos.
No Nordeste dos EUA , sete regiões de agências de pedágio formaram o “E-Z Pass Interagency Group” (IAG) em 1990 , para desenvolver compatibilidades regionais em sistemas de pedágio eletrônicos. Este sistema é o modelo para a utilização de um único tag e único bilhete de tarifa por veículo para acessar rodovias em diversos postos de pedágio.
Também na década de 90 , fortes interesses por aplicações de RFID surgiram na Europa. Ambas as tecnologias de microondas e indutiva foram utilizadas para utilizações em coleta de pedágios , controle de acesso e uma variedade de aplicações comerciais.
Um novo desenvolvimento significativo foi o desenvolvimento do sistema TIRIS pela Texas Instruments , que foi utilizado , por exemplo , em muitos automóveis para controle do início da ativação do motor. Este sistema desenvolveu novas aplicações para evitar desperdício de combustível , chips para jogos , acessos de veículos e muitas outras aplicações.
Outras companhias na Europa começaram a se envolver com RFID como o Microdesign , CGA, Alcatel , Bosch e as divisões da Philips Combitech, Baumer e Tagmaster. Um padrão Europeu foi necessário para as aplicações de pedágios na Europa , e muitas dessas companhias trabalharam no padrão da União Européia para estas aplicações.
Aplicações para pedágios e auto-estradas apareceram também em países como Austrália , China , Hong Kong , Filipinas , Argentina , Brasil , México , Malásia , Cingapura , Tailândia , Coréia do Sul , África do Sul e outros países da Europa.
Com o sucesso dos sistemas de coletas de pedágio , outros avanços surgiram , como o primeiro uso de múltiplos tags em diversos segmentos comerciais. Além disso , a partir de então um único tag (com tarifação simples ou dupla) podia ser utilizado em sistemas de coleta de pedágio eletrônico , estacionamentos , acesso à entradas e portões e acesso à universidades.Em Dallas , um único “TollTagTM” em um veículo pôde passar a ser utilizado para pagar pedágios no sistema “Noth Dallas Tollway” , e estacionamento no Aeroporto Internacional de Dallas (um dos mais movimentados do mundo) e outros diversos estacionamentos e garagens do centro da cidade , bem como em acessos à recepções e portões eletrônicos , centros empresariais e acadêmicos.
Paralelamente à enorme adoção comercial , os estudos e experimentos não pararam na década de 90 , já que diversos desenvolvimentos tecnológicos expandiram ainda mais a capacidade do RFID. Pela primeira vez , diodos Schottky baseados em microondas foram fabricados em um circuito integrado comum CMOS. Este desenvolvimento permitiu a construção de tags RFID microondas com um único CI , uma capacidade limitada nos transponders RFID indutivos. Exemplos de companhias que trabalharam neste projeto foram a IBM , a Mícron e SCS.
Com o enorme crescimento da utilização de RFID , cada vez mais companhias , instituições e órgãos se interessam pelo desenvolvimento e pela utilização desta tecnologia. Hoje pode-se dizer que a utilização do RFID é uma realidade , e ao mesmo tempo possui um enorme potencial de crescimento , graças ao interesse cada vez maior em sistemas móveis e de telemática.Testes realizados pela FCC (Federal Communications Commission) nos EUA conseguiram alocar banda na faixa de 5.9 GHz para uma vasta expansão de sistemas inteligentes de transporte com diversas novas aplicações e propósitos. Mesmo assim , equipamentos requeridos para acomodar estas novas aplicações ainda precisam de mais avanços no que diz respeito a RFID.
Abaixo , segue a tabela 1.1 com um histórico resumido da tecnologia RFID:
As décadas do RFID
|
Década |
Eventos |
|
1940-1950 |
-Radares refinados e utilizados.Muitos desenvolvimentos feitos na Segunda Guerra Mundial -RFID oficialmente inventado em 1948 |
|
1950-1960 |
-Primeiras explorações da tecnologia RFID ; experimentos em laboratórios |
|
1960-1970 |
-Desenvolvimento da teoria do RFID -Início das aplicações e trials em campo |
|
1970-1980 |
-Explosão do desenvolvimento de RFID -Aceleração dos testes de RFID -Primeiras implementações da adoção de RFID |
|
1980-1990 |
-Aplicações comerciais de RFID entram em evidência |
|
1990-2000 |
-Surgem as primeiras necessidades por padrões -Desenvolvimentos maciços em RFID -RFID torna-se parte do cotidiano |
Tabela 1.1:
As décadas do RFID Fonte: AIM Global
Um outro fator que traz muito interesse é a adoção do RFID para soluções de reconhecimento de padrões , ou seja , que substituam o atual código de barras. Esta aplicação refere-se exatamente ao tema principal deste trabalho : a tecnologia EPC.
Apesar de utilizar a tecnologia RFID , que já é vastamente utilizada ; os conceitos sobre a utilização do EPC são bem recentes ; e deram origem também a um novo termo : as Redes EPC.
As redes EPC baseiam-se no Electronic Product Code , um código eletrônico presente em cada item ou produto pertencente à uma rede EPC , ou seja , um sistema que capte através de RFID este código através de equipamentos adequados e consiga armazená-lo e manipulá-lo em um Sistema de Informação , por exemplo.
O interesse nesta nova tecnologia surgiu de diversas empresas e universidades , o que acabou resultando na criação de um centro de referência que surgiu com o objetivo de controlar , validar e distribuir informações sobre esta nova aplicação. Este centro , conhecido como Auto-id Center , propôs a criação de uma rede global que tem o potencial de identificar qualquer objeto , em qualquer lugar , automaticamente ; criando assim novas opções para automatizações e soluções comerciais , industriais , residenciais e de suplly chain , por exemplo.
O Auto-id Center foi fundado em 1999 , sendo resultado de uma parceria de quase 100 empresas globais e 5 Universidades : o MIT (Massachusetts Institute of Technology) dos EUA ; a Universidade de Cambridge , do Reino Unido ; a Universidade de Adelaide , da Austrália ; a Universidade de Keio , no Japão e a Universidade St. Gallen , da Suíça. Juntos , eles procuraram criar padrões e patentes para a utilização corriqueira das redes EPC.
Em 28 de setembro de 2001 , um teste de campo validou pela primeira vez a utilização do EPC. EPCs de embalagens de papel em uma fábrica da Procter & Gamble em Cape Giradeau (Missouri) foram lidos remotamente nos laboratórios do MIT.Os testes obtiveram sucesso e prosseguiram para uma segunda fase. Nesta fase , diversas empresas , como Coca-Cola , Kraft , Gilette , entre outras , distribuíram seus produtos com tags para centros de distribuição e vendas em 8 estados norte-americanos. Mesmo com o já grande volume de dados envolvidos , os testes também obtiveram sucesso. Uma terceira fase de testes foi iniciada em 2002 , sendo já realizada na Europa e Japão.
O Auto-id Center iniciou também o desenvolvimento , a construção e os testes de uma infra-estrutura global que tornasse possível que computadores identifiquem qualquer objeto instantaneamente. Esta infra-estrutura será abordada mais detalhadamente durante este trabalho , mas basicamente conta com os seguintes elementos:
- O próprio EPC (Electronic Product Code) ;
- O tag que está acoplado ao objeto;
- O leitor que receberá o código do produto através de RFID;
-
ONS (Object Naming Service);
-
PML (Product Mark-up Language);
- Servidor Savant (middleware do sistema).
Cabe lembrar que as tecnologias referentes ao tag e ao leitor baseiam-se na tecnologia RFID , sendo ambos componentes intrinsecamente utilizados em qualquer aplicação que a utilize.
Apesar de ainda estar passando por estágios de validações e testes , os resultados das primeiras simulações e implementações foram completamente alcançados , o que faz com que grandes empresas e redes de supermercados já tenham projetos iniciados ou mesmo em andamento para passar a utilizar integralmente a tecnologia em no máximo 2 ou 3 anos ; tempo que será dado também a seus fornecedores para se adequarem aos novos padrões.
Após reunido e estruturado , o Auto-id Center foi oficialmente fechado em 26 de outubro de 2003 , em uma reunião em Tokyo. O Centro finalizou seu trabalho e transferiu a tecnologia e a estrutura para uma nova instituição : a EPCglobal , que passou então a ter a missão de administrar e desenvolver padrões para a tecnologia.
Na continuidade deste trabalho , serão abordados diversos aspectos referentes à essa tecnologia e sua adoção. Inicialmente , será descrito o funcionamento técnico da tecnologia RFID , passando por suas especificações e padronizações já utilizados ; tendo em vista que seu funcionamento é fundamental para a compreensão das aplicações utilizando EPC. Em seguida , será feita uma abordagem técnica sobre a infra-estrutura RFID necessária para a implementação das redes EPC , tais como custo , dimensão , freqüências , modos de transmissão , distâncias suportadas para transmissão , e outros fatores relevantes aos tags RFID, além de características de leitores RFID. Em seguida , será especificada a versão atual das opções previstas e existentes para a codificação EPC , onde será levado em conta , por exemplo , quais campos um EPC pode conter e quantos bytes esses campos podem preencher. Na seqüência , serão descritos ou outros três componentes das redes EPC determinados pela EPCglobal : o Savant, a PML e o ONS. Nesses capítulos serão especificadas as características e o funcionamento destes componentes, mostrando como eles podem se integrar e como é possível integrá-los à sistemas de informação comerciais utilizados por uma empresa que tenha como objetivo implementar uma rede EPC. Ao final, será especificado um projeto que sugere um exemplo de implementação de uma rede EPC baseado nos conceitos abordados durante todo o trabalho.
|
Capítulo 2 |
Fundamentos sobre Eletromagnetismo , Rádio-Frequência e
Transmissão RFID |
2.1
Radiação Eletromagnética e
Faixas Eletromagnéticas
No século 19 , James C. Maxwell formulou modelos e equações descrevendo como a energia podia ser transmitida de um local a outro , através de um princípio que mais tarde ficou conhecido como o de propagação de radiação eletromagnética(EM).Uma maneira de compreender esse princípio é considerar uma onda de energia que emana através de uma fonte (o transmissor de radiação eletromagnética) , conforme a figura 2.1:
Figura 2.1: Radiação
eletromagnética representada como uma onda Fonte:
Auto-Id Center
A figura 2.1 mostra várias formas de representação de radiação eletromagnética , onde a figura a mostra uma onda básica ; a figura b representa uma onda com o dobro da amplitude , ou seja , com maior potência . A figura c mostra uma onda com o dobro de freqüência e a figura d mostra como a amplitude de uma onda pode ter sua continuidade alterada.
É possível controlar a natureza de uma onda eletromagnética de diversas formas. Por exemplo , uma transmissão mais potente irá resultar em uma onda maior (tecnicamente, a isso se dá o nome de amplitude) , conforme a figura b mostra. É possível também incrementar ou decrementar a oscilação da freqüência da onda. Desta forma , é possível variar a amplitude da onda ou então sua freqüência ; ou até mesmo ambas , o que pode resultar nas mais diversas e complexas formas de onda , conforme mostra a figura d. A freqüência é medida em Hertz(Hz) , ou mais comumente em Kilohertz(kHZ) , Megahertz(MHz) , ou Gigahertz(GHz) , conforme a tabela 2.1 abaixo:
|
Kilohertz |
1 kHz = 1000 Hz = 103 Hz |
|
Megahertz |
1 MHz = 1000 kHz = 1000000 Hz = 106 Hz |
|
Gigahertz |
1 GHz = 1000 MHz = 1000000 kHz = 1000000000 Hz = 109 Hz |
Tabela 2.1:A
relação entre Kilohertz , Megahertz e Gigahertz Fonte: Auto-Id Center
A freqüência de uma transmissão eletromagnética é particularmente interessante , tendo em vista que vastas faixas de freqüência são possíveis ; e as características da transmissão variam muito dependendo da freqüência utilizada. Desta forma , freqüências similares tem propriedades também similares , movimentando-se através dessa faixa de freqüências eletromagnéticas (conhecido também como faixa eletromagnética) , resultando em mudanças dramáticas em propriedades , como por exemplo o comportamento da onda ao passar através de diferentes materiais.
Para caracterizar essas diferentes propriedades , os físicos segmentaram a faixa eletromagnética em diferentes regiões (ou bandas) , com a idéia de que em uma banda particular as propriedades devem ser similares , pois as freqüências são também similares. Essas bandas são apenas uma forma genérica de se referirem às faixas eletromagnéticas – muitas vezes uma menor ou maior faixa de freqüências são relevantes , e neste caso pode ser apropriado para se referir a um conjunto de bandas ou mesmo apenas uma banda. Na figura 2.2, pode-se visualizar a faixa eletromagnética e a sua divisão em bandas :
Figura 2.2: A faixa eletromagnética Fonte: Auto-Id Center
2.2 Ondas de Rádio
Dentro da faixa
eletromagnética citada anteriormente , há uma vasta faixa de freqüências ,
situada entre 300 kHz e 3 GHz , que compartilham determinadas características e
se referem às ondas de rádio.
As freqüências das diferentes bandas eletromagnéticas que são consideradas ondas de rádio estão listadas na tabela 2.2. É possível verificar que a banda UHF tecnicamente refere-se à qualquer freqüência que está na faixa entre 300 MHz e 3 GHz , o que inclui a freqüência de 2,5 GHz , que é a freqüência das microondas. Contudo , às vezes “UHF” é também usado para se referir a uma menor banda que na verdade exclui as microondas.
|
Designação da Banda |
LF |
MF |
HF |
VHF |
UHF |
SHF |
|
Freqüência |
30-300kHz |
300kHz-3MHz |
3-30MHz |
30-300MHz |
300MHz-3GHz |
3-30GHz |
|
Comprimento de Onda |
10-1km |
1000-100m |
100-10m |
10m-1m |
1m-0,1m |
0,1-0,01m |
Tabela 2.2:Bandas
da faixas eletromagnéticas referentes às ondas de rádio Fonte:
Auto-Id Center
Notas:
LF – Low Frequency (Baixa Freqüência)
MF – Medium Frequency (Média Freqüência)
HF – High Frequency (Alta
Freqüência)
VHF – Very High Frequency (Freqüência Muito Alta)
UHF – Ultra High Frequency (Freqüência Ultra-Alta)
SHF – Super High Frequency (Freqüência Super Alta)
2.3 Transmissão e Recepção de
Ondas de Rádio
Há diferentes formas de criar uma onda eletromagnética (acender um fósforo ou isqueiro causa luz visível a ser emitida , por exemplo) , mas ondas de rádio são tipicamente geradas por circuitos eletrônicos conectados à uma antena. Esse circuito eletrônico pode geralmente controlar através de uma pequena extensão a freqüência e a amplitude da onda que é gerada. Uma fonte externa de energia elétrica é necessária para prover a energia para transmitir a onda de rádio.E , sabendo-se que componentes eletrônicos não são nunca 100% eficientes , nem toda energia provida pelo circuito irá passar através da transmissão de rádio.
É particularmente útil para um transmissor de rádio variar a natureza da onda que está sendo transmitida. Fazendo isso continuamente , torna-se possível representar (ou codificar, ou modular) informações internas no transmissor de rádio. Em um nível mais genérico , pode-se imaginar um código-Morse como um sistema onde o transmissor alterna entre ligado e desligado para representar diferentes letras em uma transmissão privada.Por outro lado , é também possível imaginar esquemas muito mais sofisticados , onde a freqüência e a amplitude de uma onda transmitida podem variar de diversas formas , podendo assim codificar muitas informações.
As ondas de rádio podem ser recebidas de uma forma análoga , com uma antena conectada a um circuito eletrônico. É possível construir um sistema receptor onde uma fonte de energia externa não é necessária - toda a energia para ativar os circuitos eletrônicos é derivada da onda de rádio que está sendo recebida. Isso é exatamente o mecanismo usado por cristais de rádio, por exemplo. Contudo , receptores de rádio geralmente fazem uso de uma fonte de energia externa como uma bateria ou circuitos elétricos convencionais. Nos dois casos , o função do receptor é decodificar a informação que está sendo transmitida , para que então possa passá-la para algum outro componente subseqüente do sistema eletrônico utilizado.
Para que um receptor de rádio tenha conhecimento das ondas de rádio que estão sendo recebidas , é preciso saber de que forma a informação foi codificada pelo transmissor. Isso é conhecido como o protocolo de camada física , ou às vezes como a interface aérea do sistema.
2.4 Alcance de um Sistema de
Comunicação de Rádio
Para qualquer receptor e transmissor de rádio , há uma máxima distância (ou alcance) na qual a comunicação pode operar normalmente.Se a separação entre o transmissor e o receptor é incrementada além desta distância , o receptor não irá mais recriar a informação que está sendo recebida de forma correta.É prudente que se opere sistemas de comunicação via rádio com uma certa margem , e não à máxima distância , já que essa distância exata pode variar em diversos momentos e desta forma pode-se assegurar uma performance confiável da comunicação.
A exata distância será afetada por uma série de fatores , mas pode-se resumir em quatro principais:
1. A energia contida na onda transmitida
2. A sensibilidade do equipamento receptor
3. O meio por onde as ondas viajam
4. A presencia de interferência
Esses itens são auto-explicativos , mas é importante notar a relação entre a energia e a distância. Como as ondas de rádio viajam a partir da antena transmissora , elas acabam sendo dispersadas em todas as direções.Isso significa que todas as vezes que a distância do transmissor dobra , a proporção da onda original que é disponível para a recepção é dividida por quatro. A isso se dá o nome de relação inversa quadrática , conforme mostra a figura 2.3.
Figura 2.3:
Relação inversa quadrática em transmissões via rádio Fonte:
Auto-Id Center
São também importantes os impactos relativos aos meios de transmissão nas comunicações via rádio. Quando a radiação eletromagnética passa através de materiais , ela pode ser absorvida por alguma outra extensão , dependendo das propriedades do material e do tipo de radiação . Essa absorção resulta na redução da força da radiação , resultando em um processo conhecido como atenuação. Essa atenuação pode aumentar dependendo da natureza do material.
Luzes visíveis são absorvidas relativamente fácil , enquanto as ondas de rádio tendem a passar através de materiais (gases especiais da atmosfera , como nitrogênio e oxigênio , e também papel , papelão e certos plásticos) , com atenuação de radiação reduzida. Outros materiais (metais e líquidos , por exemplo) , tem um efeito d atenuação mais poderoso , contudo a atenuação pode depender também da freqüência da onda.Mais uma vez , as diferentes freqüências que estão dentro de uma mesma banda irão mostrar propriedades similares entre si.
Além da atenuação por absorção , certas freqüências de ondas de rádio também estão suscetíveis para algo conhecido como interferência de múltiplos caminhos . Isso ocorre quando ondas são refletidas por objetos que estão no meio de transmissão , e as reflexões interferem no formato original da onda. Isso faz com que o rádio receptor tenha muita dificuldade de determinar a onda original , e no pior caso há posições (chamadas nulas) onde a recepção não é possível , mesmo que o transmissor e o receptor estejam relativamente próximos um do outro.
De forma parecida , se houver alguma outra onda de rádio sendo transmitida em uma freqüência similar , então isso irá causar interferência da mesma maneira.
2.5 Antenas e Comprimento de Ondas
Como já mencionado , a antena é uma parte crítica de um sistema de comunicação de rádio.O tamanho , formato e as propriedades específicas de uma antena dependem muito da freqüência da onda que será transmitida ou recebida.
Em geral , o tamanho da antena é proporcional ao comprimento de onda de rádio. O comprimento de onda é essencialmente outra forma de representar a freqüência de uma onda de rádio. Assim como a freqüência é medida em Hertz , o comprimento de onda é basicamente medido em metros. Freqüências altas são equivalentes a pequenos comprimentos de onda e vice-versa.(Para mais informações , consultar a tabela 2.2).
É interessante perceber que tipicamente a antena é mais eficiente em uma freqüência única (a freqüência central) , ou seja , ela não irá funcionar bem em freqüências abaixo ou acima desta. Entretanto , para uma dada freqüência , a mesma antena pode ser utilizada igualmente para transmitir ondas de rádio ou também recebê-las.
Diferentes tipos de antena tem diferentes padrões de radiação , ou seja , as direções nas quais elas podem transmitir ou receber radiação eletromagnética. Muitas antenas são direcionadas , o que significa que elas trabalham melhor em uma certa orientação.
Além do aspecto direcional do padrão de radiação , as antenas podem produzir radiação que são polarizadas linearmente ou polarizadas circularmente . O ponto principal para se ter em mente relativo ao tipo de polarização é que no caso da polarização linear , as antenas transmissoras e receptoras devem ser paralelas entre si para maximizar a força do sinal recebido.Antenas com polarização circular não possuem esta restrição , a orientação relativa entre as duas antenas é menos crítica.
2.6 Operação Básica em um Sistema RFID
A identificação por rádio-frequência (do inglês RFID-Radio Frequency Identification) possui esta descrição porque está relacionada com a identificação de objetos utilizando radiação eletromagnética em rádio-frequências.
Na tabela 2.2 pode-se visualizar que uma grande faixa dentro da faixa eletromagnética são referentes à rádio-frequência (RF) , o que resulta em diferentes formas de RFID. Mais uma vez , os sistemas RFID podem ser categorizados baseados na banda eletromagnética em que eles operam.Sistemas RFID que situam-se na mesma banda irão geralmente mostrar características similares ; os que estão em outras bandas devem operar de forma muito diferente e então serem mais ou menos apropriados para uma determinada aplicação.
Um sistema RFID contém dois componentes – um leitor RFID e um tag RFID, que nada mais é do que um pequeno componente (um chip, por exemplo) acoplado ao objeto a ser identificado.Como o próprio nome diz , o leitor RFID é quem realmente transmite em um sistema RFID. Os componentes eletrônicos do leitor usam uma fonte de energia externa para gerar o sinal que dirige a antena leitora e que cria a onda de rádio apropriada. Essa onda de rádio deve ser recebida por um tag RFID , que por sua vez “reflete” parte da energia que recebe em um caminho específico (baseado na identidade do tag). Conforme esta reflexão está em andamento , o leitor RFID também atua como um receptor de rádio , podendo assim detectar e codificar o sinal refletido para que assim possa identificar o tag. Esse processo é mostrado na figura 2.4:
Figura 2.4: O
princípio de operação em um sistema RFID
Fonte: Auto-Id Center
Na parte a) da figura vemos que o leitor RFID inicia a transmissão da onda de rádio, que é utilizada para energizar o tag RFID. Já na parte b) da figura , vemos que o tag reflete a energia de volta para o leitor , que agora atua como um receptor , para que possa haver a comunicação da identidade do tag.
Um sistema RFID é especificamente desenvolvido para que seja assimétrico – o leitor é maior , caro e muito mais potente se comparado com o tag RFID.Há diferentes tipos de sistemas RFID , mas uma categorização básica é baseada na fonte de energia usada para o tag:
1) Sistemas RFID com tags passivos – Neste caso o tag não requer bateria. Ao invés disso , ele usa a energia da onda de rádio para sua operação.O custo é menor , mas a performance é afetada.
2)
Sistemas RFID com tags
semi-passivos – Neste caso o tag possui uma bateria acoplada para melhorar a performance. A
bateria energiza o circuito interno do tag
, mas não é utilizada para gerar ondas de rádio.
3)
Sistemas RFID com tags
ativos – Usa baterias para a totalidade da operação
, e pode inclusive gerar ondas de rádio pró-ativamente mesmo na ausência de um
leitor RFID.
Sistemas RFID com tags passivos são o tipo mais comumente encontrados , e são geralmente referenciados simplesmente como “Sistemas RFID”.
No Capítulo 3 deste trabalho , serão melhores detalhados e especificados o funcionamento e as características dos componentes de um sistema RFID (leitores e tags) a fim de uma melhor compreensão da infra-estrutura necessária para o desenvolvimento de um sistema desta natureza.
2.7 Considerações sobre alcance em
Sistemas RFID
Em um sistema RFID , o termo alcance refere-se à máxima distância operacional entre a antena leitora e o tag ; e o campo do leitor refere-se a área específica de operação.
A freqüência de operação usado em um sistema RFID tem um grande efeito no alcance da operação. Análises sobre a estrutura física de comunicações RFID mostram que a freqüência ótima está na faixa entre 400 e 500 MHz. Este tipo de análise não pode ser feita de forma genérica , pois há diversos fatores que devem ser levados em conta e isso resultará em diferentes efeitos dependendo da aplicação.Exemplos de fatores que serão afetados pela escolha da freqüência incluem : tamanho da antena do tag , facilidade em distribuir energia ao tag , facilidade da comunicação de volta do tag ao leitor , além do custo e velocidade da comunicação.
O alcance de sistemas RFID que operam na banda UHF é governado basicamente pelos princípios descritos no sub-capítulo 2.4 (Alcance de um Sistema de Comunicação de Rádio). Isso significa que a habilidade do leitor de se energizar e se comunicar com o tag é baseado na lei inversa quadrática (1 / r 2 ) , assim como o caminho de volta dos sinais refletidos de volta do tag para o leitor. A operação irá também ser afetada pelas condições do meio de transmissão e pela interferência de outras fontes de rádio na mesma freqüência.
Sistemas RFID que operam na banda HF da faixa eletromagnética trabalham de uma forma bem diferente do que os que utilizam a banda UHF , e acaba sendo muito útil compreender essa diferença fundamental e também os efeitos que ocorrem no alcance da operação. Se a comunicação ocorre em um curta distância (relativa ao comprimento da onda de rádio), recebe a definição de operação near-field. Sabendo-se que sistemas RFID em HF (3-30 MHz) utilizam ondas com o comprimento de onda em torno de 10 a 100 metros , se a distância da comunicação é muito menor do que isso (que é o caso do RFID) , então isso é uma comunicação near-field . Comunicações near-field são baseadas em efeitos de campo magnético , que por sua vez tem uma relação de sexta potência (1/r 6) com o alcance. (O modo near-field será melhor detalhado no Capítulo 3) .
Além disso , se uma antena direcionada é utilizada , os protocolos de radiação irão também afetar o campo de leitura.
2.8 Lendo múltiplos tags
Uma das vantagens de sistemas RFID em relação a barcodes (código de barras) e outras técnicas de identificação que são geralmente citadas , é exatamente a habilidade dos sistemas em identificar múltiplos tags no campo de alcance de um leitor simultaneamente. De fato , a identificação de múltiplos tags é raramente utilizada simultaneamente na prática – em geral , os tags são identificados (ou singularizados) consecutivamente , em um intervalo de tempo muito curto. Para que um tag não interfira em outro , alguns mecanismos devem ser construídos de acordo como o sistema RFID opere . A isso se dá o nome de protocolo de anti-colisão , porque previne que respostas de diferentes tags colidam umas com as outras. Há diferentes formas de construir um sistema RFID que utilize anti-colisão. O mais comum é que o leitor seja o responsável por prevenir colisões (o leitor arbitra em relação aos tags) , em uma técnica conhecida como reader talks first.
Dependendo do protocolo utilizado no leitor RFID , as velocidades nas quais os diferentes tags podem ser identificados (neste caso , a velocidade de leitura) podem variar. A velocidade de leitura é geralmente expressa como tags por segundo que possam ser identificados , mas é importante compreender que interpretar essa situação pode eventualmente ser errônea. É possível que um sistema RFID leia a identificação de um único tag centenas de vezes em um mesmo segundo , mas por outro lado o mesmo sistema pode não conseguir ler a identificação de centenas de tags em um segundo.O que geralmente importa em aplicações reais é o tempo levado para identificar todos os tags abrangidos em um campo de leitura , ou seja , o tempo até o último tag.
2.9 Utilizando múltiplos leitores
Em muitas aplicações , torna-se necessário instalar diversos leitores RFID em relativa proximidade uns dos outros.Como resultado , eles podem estar no mesmo raio de alcance entre si , ou seja , eles tem o potencial de provocar interferência nas transmissões.Uma vez que um leitor RFID é desenvolvido para receber um minúsculo sinal refletido de um tag , ele está particularmente suscetível à qualquer transmissão (relativamente poderosa) de outros leitores no mesmo instante.Isso está ligado ao compartilhamento da banda de freqüência com outros usuários em potencial , o que mais uma vez pode causar interferências.
Um dos dois diferentes mecanismos é geralmente utilizado para evitar interferências. O primeiro , conhecido como espalhamento de alcance (do inglês spread spectrum) , baseia-se em propagar uma transmissão de rádio através de uma relativa grande banda de diferentes freqüências em um forma especial , sendo que múltiplas transmissões simultâneas (de diferentes sistemas , por exemplo) irão no final utilizar diferentes partes da faixa rádio-eletromagnética e assim poderão operar largamente sem interferir umas nas outras.Na prática , há duas variantes mais comuns desta técnica , chamadas salto frequencial (do inglês frequency hopping) e seqüência direta(do inglês direct sequence) de espalhamento de alcance (conhecidas como FHSS e DSSS respectivamente).
O segundo mecanismo , que foi proposto na Europa e que também tem larga utilização no Japão é conhecido como listen before talk , ou também como dynamic frequency selection.
|
Capítulo 3 |
Propriedades e Características de Componentes RFID |
3.1
Tags RFID
3.1.1 Modelos de Construção de Tags
Conforme citado no Capítulo 2 , um tag RFID é um pequeno componente acoplado a um objeto que faça parte de um sistema de identificação. Os tags podem ser fabricados de diversas maneiras , projetados para diferentes aplicações e ambientes. O processo básico de montagem inicia-se a partir de um material substrato (Papel , PVC , PET , etc.) sobre o qual uma antena feita de um dos diversos materiais condutivos como tinta prata , alumínio e cobre é depositada. A antena é conectada junta ao próprio chip do tag , sendo que para isso utilizam-se técnicas conhecidas como wire bonding e flip chip . Finalmente um revestimento protetor feito a partir de materiais como PVC laminado , resina de epóxi ou papel adesivo é opcionalmente adicionado , a fim de resistir à diversas condições físicas encontradas em muitas aplicações , como atrito , impacto e corrosão.
Abaixo segue a figura 3.1, que representa a seqüência básica de montagem de um tag RFID:
Figura 3.1
Processo Básico de Montagem do Tag Fonte: Laran RFID
Abaixo seguem alguns exemplos de possíveis formatos de tags:
- Cartões de crédito de tamanhos flexíveis com adesivos na parte traseira
- Fichas e moedas
- Tags embutidos – anexados por injeção em produtos plásticos , como caixas
- Pulseiras
- Chaves eletrônicas de segurança (Key Fobs)
- Tags desenvolvidos especialmente para caixas e palhetas
- Tags de papel
O tipo de material utilizado nos métodos de fabricação de montagem dos tags impactam diretamente em seu custo final (aproximadamente 30%) , e também na sua performance de comunicação . Para a maioria das aplicações , o custo dos tags é uma das maiores considerações a serem feitas para que seja possível uma larga adoção da tecnologia, sendo o preço de US$ 0,05 o preço-alvo discutido atualmente.Ao mesmo tempo , a área necessária para os chips UHF (utilizados nestas aplicações) é de 0,3 mm2 , resultando em um custo de produção de US$ 0,02 , restando desta forma apenas 3 centavos para o restante do custo e da margem de lucro , o que ainda dificulta o atingimento do preço-alvo. Uma das alternativas para que se chegue neste preço é a produção em massa de tags , neste caso chegando-se mesmo à bilhões de tags produzidos. Alguns grandes fabricantes já possuem projetos com esta característica para que se chegue ao objetivo do mercado.
Uma outra forma de fabricação utilizada resulta em tags conhecidos como coil-on chip tags. Neste tipo de fabricação , a antena é depositada diretamente na superfície do chip do tag. Embora a distância de comunicação seja limitada em aproximadamente 3mm , o resultado é um tag microscópico que pode ser ocultado , por exemplo , em cédulas de dinheiro , como já proposto por alguns fabricantes . Versões HF e UHF para este tipo de tag já são oferecidas atualmente no mercado.
Outro tipo existente é o tag IC. Este tag é projetado e construído utilizando um dos processos mais avançados de montagem de circuitos integrados conhecidos atualmente . O resultado é altamente expressivo , comparando-se com o tamanho de área padrão para chips UHF (0,3 mm2) , já que a sua área pode ser expressa fisicamente como o ponto a seguir: •.
Figura 3.2 Estrutura Interna do Chip dos Tags IC Fonte: Laran RFID
Em termos de poder computacional , os tags RFID são muito limitados , possuindo apenas uma capacidade lógica básica , além de estados de máquina capazes apenas de decodificar instruções simples. Porém , isso não significa que sejam fáceis de serem projetados , pois de fato existem vários desafios em questão , como o de se utilizar baixo consumo de energia , gerenciar ruídos RF e manterem-se de acordo com a rigorosa regulação relativa à emissões em transmissões.Outros importantes circuitos permitem que o chip transfira energia do campo de sinalização do leitor , e o converta através de um retificador em uma tensão de alimentação. O clock do chip é normalmente extraído do sinal vindo do leitor. Além disso , a maior parte dos tags contém uma certa quantidade de MNV (Memória Não-Volátil) , como EEPROMs , para que se possa armazenar dados.
A quantidade de dados armazenada depende da especificação do chip , e pode variar de apenas simples números identificadores de cerca de 96 bits , indo até 32Kbits quando há diversas especificações do produto ou objeto. De qualquer forma , capacidades maiores de dados e de armazenamento estão diretamente ligadas com o tamanho do chip , conseqüentemente deixando os tags mais caros.
No caso do EPC (Electronic Product Code) , que será mais detalhado durante este trabalho , o código ocupa no máximo 256 bits , o que possibilita a utilização de chips menores , conseqüentemente gerando custos menores , o que é visto como uma grande vantagem para a sua adoção em diversas aplicações.
3.1.2 Classes de Tags
Uma das principais formas de se categorizar os tags RFID consiste em separá-los por sua capacidade de ler e escrever dados.Essa categorização está dividida em 4 classes , que serão descritas a seguir:
Classe 0 – Read Only – Programado
de Fábrica
Estes são os tipos mais simples de tags , onde os dados , que são geralmente simples números identificadores , são escritos apenas uma vez durante o processo de construção do tag.A memória é então desabilitada para qualquer possível atualização futura.A Classe 0 é também utilizada para definir uma categoria de tags conhecida como EAS (Electronic Article Surveillance) ou dispositivos anti-roubo , que não possuem ID e apenas anunciam sua presença quando passam através do raio de alcance da antena.
Classe 1 – Write Once Read
Only (WORM) – Programado de Fábrica ou por Usuário
Neste caso o tag é fabricado sem conteúdo de dados em sua memória . Os dados podem então ser escritos pelo fabricante ou pelo usuário – porém apenas uma vez . Depois disso , nenhuma futura escrita de dados é permitida e o tag poderá apenas ser lido.Tags deste tipo geralmente atuam como simples identificadores.
Classe 2 – Read Write
Este é o tipo mais flexível de tag , onde os usuários possuem acesso para ler e escrever dados na memória dos tags. Eles são tipicamente utilizados como loggers de dados , e por isso contém mais espaço de memória do que quando é necessário para armazenar simplesmente um número identificador.
Classe 3 –
Read Write – Com sensores on-board
Estes tags contém sensores on-board para gravar parâmetros como temperatura , pressão e movimento , que pode então ser armazenado na memória do tag. Como a leitura do sensor deve ser feita na ausência de um leitor , os tags desta classe são semi-passivos ou ativos.
Classe 4– Read Write – Com
transmissores integrados
Estes tags funcionam como dispositivos de rádio em miniatura , que podem comunicar-se com outros tags e dispositivos sem a presença de um leitor . Isso significa que eles são completamente ativos com sua própria fonte de alimentação.
Abaixo a tabela 3.1, que resume a divisão em Classes dos tags RFID:
|
Classe |
Descrição Genérica |
Memória |
Fonte de Energia |
Aplicações |
|||
|
0 |
EAS |
EPC |
Nenhuma |
EPC |
Passivo |
Anti-Furto |
ID |
|
1 |
EPC |
Read-Only |
Indiferente |
Identificação |
|||
|
2 |
EPC |
Read-Write |
Indiferente |
Logger de Dados |
|||
|
3 |
Sensor Tags |
Read-Write |
Semi-Passivo/Ativo |
Sensores |
|||
|
4 |
Smart Dust |
Read-Write |
Ativo |
Redes Ad Hoc |
|||
Tabela 3.1:
As diferentes classes de tags Fonte: Laran RFID
Obs:Além da divisão de classes apresentada acima , há uma outra abordagem de classes em RFID , que é sugerida pelo Auto-Id Center(atualmente EPCglobal). Esta abordagem é conhecida como Classes RFID , e , apesar de também tratar aspectos referentes às capacidades dos tags , possui uma abordagem mais conceitual e menos comercial do que a citada acima , a fim de se criar uma referência oficial do tema que seja reconhecida internacionalmente , assim como outras normas e padrões especificados por outros órgãos oficiais . Esta abordagem ainda passa por aprimoramentos e será melhor detalhada no Capítulo 4 deste trabalho , que descreverá normas , padrões e legislação para RFID.
Além de se basear no conceito de
classes de tags para projetar uma aplicação RFID, outros fatores também devem
ser levados em conta para um projeto , como por exemplo os citados abaixo:
- Tamanho e formato
- A proximidade dos tags entre si
- Durabilidade
-
Possível reutilização do tag
- Resistência à possíveis agressões do ambiente (corrosão , vapor , etc.)
- Polarização e orientação dos tags em relação ao campo de leitura
- Exposição à diferentes níveis de temperaturas
- Distância de comunicação
- Influência de materiais como metais e líquidos
- Características do ambiente (ruído elétrico , outros dispositivos de rádio e equipamentos)
- Freqüência de operação (LH , HF ou UHF)
- Normas e protocolos de comunicação suportados (ISO , EPC)
- Regulamentações regionais
- Necessidade do tag armazenar mais do que simplesmente um ID
- Anti-colisão
- Velocidade dos tags em movimentações próximas ao campo de leitura
- Suporte e compatibilidade do leitor
- Necessidade de segurança adicional para o tag (encriptação)
3.1.3 Tags Passivos e Ativos
Figura 3.3 Considerações para escolha do tag RFID Fonte: Laran RFID
A figura 3.3 mostra que a primeira consideração a ser feita na escolha de um tag está no fato dele ser passivo , semi-passivo ou ativo.Tags passivos podem ser lidos de uma distância de até 4 ou 5 metros usando-se a banda de freqüência UHF , enquanto que os outros tipos de tags (semi-passivos e ativos) podem alcançar distâncias muito maiores , de até 100 metros para semi-passivos e de quilômetros para ativos.Essa larga diferença na performance de comunicação pode ser explicada pelo seguinte:
- Tags passivos utilizam o sinal do leitor como uma fonte de energia para o chip e para a comunicação do leitor e para o leitor.A disponibilidade de energia proveniente do leitor , não só é reduzida rapidamente com a distância , como também é controlada por regulamentações rigorosas , resultando em uma comunicação limitada na distância de 4 a 5 metros quando se usa a banda de freqüência UHF (860 MHz – 930 MHz).
- Tags Semi-Passivos são construídos em baterias e por isso não requerem energia do sinal proveniente do leitor para energizar o chip. Isso possibilita que eles funcionem com níveis de energia muito mais baixos , resultando em grandes distâncias de até 100 metros. A distância é principalmente limitada ao fato do tag não possuir um transmissor integrado , e neste caso também é obrigada a utilização do raio de alcance do leitor para realizar a comunicação de volta ao leitor.
- Tags Ativos são dispositivos energizados por baterias que possuem um transmissor ativo on-board . Diferentemente dos tags passivos , os tags ativos geram energia RF e a aplicam para a antena. Esta independência do leitor significa que eles podem se comunicar à distâncias de até quilômetros.
Atualmente é dispensada uma atenção muito grande para os tags passivos , que são os mais adequados para aplicações que tenham larga escala de utilização , como por exemplo propõe o conceito das redes EPC.
Além disso , a partir do interesse e do investimento de diversas empresas no ramo de RFID , atualmente são encontrados tags RFID para diferentes freqüências : LF , HF , UHF e microondas , como mostra a tabela 3.2. HF e UHF são as mais adequadas para a maioria das aplicações , como por exemplo supply chain e redes EPC. No futuro , é esperado que o UHF , devido ao seu superior alcance de leitura , torne-se a freqüência dominante ; porém não significando que freqüências LF e microondas não sejam utilizadas em casos específicos.
A tabela 3.2 mostrada abaixo aponta vantagens , desvantagens , aplicações e outras características quando compara-se tags passivos e ativos , considerando-se tags semi-passivos como uma ramificação dos ativos.Nela é possível compararem-se custo , alcance , em que faixas de freqüências os tags estão disponíveis , além de aplicações específicas para cada tipo descrito.
|
Tag |
Vantagens |
Desvantagens |
Observações |
|
Passivo |
- Tempo de vida maior - Maior variedade de formatos possíveis - Os tags são mecanicamente mais flexíveis - Custos menores |
- Distância limitada entre 4 e 5 metros - Rigorosamente controlado por regulamentações locais |
- É o mais utilizado em aplicações RFID - Os tags podem ser LF, HF ou UHF |
|
Semi-Passivo |
- Possibilita grandes distâncias na comunicação - Pode ser utilizado para gerenciar outros dispositivos, como sensores (Temperatura , Pressão , etc.) - Não falham diante das mesmas regulamentações de energia estipuladas sobre dispositivos passivos |
- Maior custo – devido à bateria e à estrutura física do tag - Confiabilidade: é impossível determinar quando uma bateria está boa ou ruim , particularmente em ambientes com múltiplos transponders - Proliferação de propagação quando múltiplos transponders atuam paralelamente , com risco potencial de danos químicos e tóxicos ao ambiente |
- Utilizado principalmente em sistemas de tempo
real para rastreamento de materiais de alto valor ou equipamentos por toda
uma fábrica - Os tags
são UHF |
|
Ativo |
- Utilizado em logística, para rastreamento de containers , caminhões , etc. - Os tags são UHF ou microondas. |
Tabela 3.2: Tabela de comparação entre tags passivos e ativos Fonte: Laran RFID
3.1.4 Métodos de Comunicação entre tags e leitores
A fim de receber energia e se comunicarem com os leitores , os tags passivos podem utilizar dois métodos mostrados na figura 3.4 . O primeiro , conhecido como near field, emprega o casamento indutivo do tag com o campo magnético que circula na proximidade da antena do leitor (assim como um transformador). Já no segundo método , denominado far field , são utilizadas técnicas similares à dos radares (reflexão dispersa) , que funcionam a partir do princípio de intersecção com o campo elétrico.O método near field é geralmente utilizado por sistemas RFID nas freqüências LF e HF , e o far field para grandes faixas de leitura em UHF e sistemas RFID microondas.A barreira teórica entre os dois métodos depende da freqüência utilizada , e é de fato diretamente proporcional à λ / 2π , onde λ = tamanho da onda. Isso significa , por exemplo , aproximadamente 3,5 m para um sistema HF e 5 cm para UHF , com ambos sendo reduzidos quando outros fatores são levados em conta.
Figura 3.4 Métodos de comunicação entre tags e leitores Fonte: Laran RFID
3.1.5 Tags
LF e HF
Os tags utilizados nas freqüências LF e HF utilizam casamento indutivo entre duas bobinas (antena do tag e antena do leitor) , a fim de se fornecer energia ao tag e promover trocas de informações.As bobinas em si são na verdade circuitos LC ajustados , que quando colocados na freqüência correta de transmissão(por exemplo 13,56 MHz para HF)maximizam a energia transferida do leitor para o tag. Quanto maior a freqüência , menos voltas na bobina são requeridas (13,56 MHz tipicamente utiliza entre 3 e 5 voltas).A comunicação do leitor para o tag ocorre a partir da modulação de sinal , que então altera sua amplitude de acordo com a informação digital a ser transmitida (sinal da banda base).O resultado é a já conhecida técnica conhecida como AM , ou Modulação por Amplitude. O circuito receptor do tag é capaz de detectar o sinal modulado , e então decodifica a informação original para si. Entretanto , enquanto o leitor possui energia para transmitir e modular seu sinal , o tag passivo não a possui.
Por isso , para que o tag consiga responder de volta ao leitor , é utilizado o casamento indutivo. Desta forma , a segunda bobina (a antena do tag) realiza uma alteração da carga e o resultado é visto na primeira (a antena do leitor).O chip do tag consegue o mesmo efeito , alterando então a impedância da antena através de um circuito interno , que é modulado na mesma freqüência do sinal do leitor.De fato , a complexidade pode ser um pouco mais alta do que isso , porque se a informação está contida na mesma freqüência da do leitor , então ela será sobreposta por ele . E , devido à fraca interação indutiva entre o leitor e o tag , a informação pode também ser dificilmente detectada no campo de transmissão.Para resolver este problema , a informação real é , ao invés disso , geralmente modulada nas bandas marginais de uma freqüência transmissora mais alta , que é mais facilmente detectada pelo leitor. Por exemplo , em uma transmissão na freqüência de 13,56 MHz (HF) , pode haver uma modulação da informação em uma banda superior lateral de 13,77 MHz.
3.1.6 Tags UHF
Tags passivos operando em freqüências UHF ou superiores usam técnicas de modulação (AM) similares aos de freqüências menores , além de também receber sua energia do sinal do leitor. Entretanto , o que é diferente é a forma como a energia é transferida ; além do design apropriado das antenas para captá-la. Isso é realizado através do método far field , que está situado dentro da Teoria Eletromagnética na região aonde os campos elétricos e magnéticos de um condutor (antena) se chocam e propagam-se no espaço como uma onda combinada. Neste ponto , não há a mínima possibilidade de casamento indutivo como em sistemas HF , pois o campo magnético não está mais ligado à antena.Transmissões desta onda através de far field são a base de todas as comunicações modernas de rádio. Em alguns sistemas , como linhas de transmissão (em cabos coaxiais) , a propagação destas ondas é restrita o máximo possível através de protetores especiais que inibem sua energia. Para as antenas , ocorre o inverso , pois a propagação é estimulada. Quando a onda de propagação do leitor colide com a antena do tag na forma de dipolo (conforme mostra a figura 3.4) , parte da energia é absorvida a fim de energizar o tag , e uma pequena parte é refletida de volta para o leitor em uma técnica conhecida como reflexão dispersa (backscatter).A teoria mostra que para o nível ótimo de energia transferida , o dipolo deve ser igual a λ/2 , o que significa um tamanho de aproximadamente 16 cm para a freqüência padrão UHF utilizada em RFID. Na realidade , esse dipolo é constituído de duas partes de λ /4 de tamanho. Um desvio destas dimensões pode trazer sérios impactos em performance.
Assim como em tags de freqüências inferiores , um tag passivo UHF também não possuí energia para transmitir independentemente. A comunicação do tag para o leitor é propiciada pela alteração de impedância de entrada da antena ao mesmo tempo em que o pacote de dados é transmitido.Isso resulta em energia refletida de volta para o leitor , que é alterada ao mesmo tempo em que os dados são modulados.
Do ponto de vista das aplicações , usando a técnica de modulação por reflexão dispersa (backscatter) em far fields , muitos problemas que não são presentes em HF e sistemas de freqüências inferiores acabam aparecendo.Um dos mais importantes ocorre devido ao fato que o sinal emitido pelo leitor não é apenas refletido pela antena do tag , mas também por qualquer objeto que opere com comprimentos de onda similares aos usados na transmissão. A reflexão deste sinais , se sobreposta ao sinal principal do leitor , pode levar à falhas , ou até a mesmo ao cancelamento da operação.
3.2
Leitores RFID
3.2.1 Características Gerais sobre
Leitores
Leitores
(ou interrogadores , como também podem ser chamados), são elementos essenciais
em qualquer sistema RFID , e por isso fazem parte do processo de avaliação e
seleção do produto. Até o recente surgimento em aplicações para supply chain e tags EPC , os leitores eram principalmente utilizados para sistemas
de acesso de controle e outras poucas aplicações RFID , ou seja , em aplicações
onde o problema de tratar e operar muitos tags
e dados não era impactante. Com o surgimento destas novas tecnologias
mencionadas , esse quadro tem se alterado , e por isso muitos fabricantes estão
começando a desenvolver uma nova geração de produtos que sejam capazes de
gerenciar os problemas das aplicações que serão específicas para as redes EPC e
outras recentes aplicações.
Abaixo seguem os critérios básicos para a escolha de um leitor RFID:
- Freqüência de Operação (HF ou UHF) – Algumas companhias estão desenvolvendo leitores multi-frequência
- Flexibilidade do Protocolo – Suporte à diferentes protocolos (ISO, EPC, Proprietário) – Muitas companhias oferecem suporte à multi-protocolo , porém não à todos
-
Diferentes regulamentações regionais
-Freqüência UHF entre 902-930 MHz nos EUA e 869 MHz na Europa
-Regulamentações de Energia:4 Watts nos EUA e 500mW na Europa
-Gerenciamento de Frequency Hopping nos EUA e Duty Cicle na Europa
-
Compatibilidade para redes de dados
-TCP/IP
-LAN sem fio (IEEE 802.11)
-LAN Ethernet (10 baseT)
-RS 485
-
Habilidade para gerenciar vários leitores
simultaneamente
-Via concentradores
-Via middleware
-
Habilidade para atualizar o firmware do
leitor em ambientes de produção
-Via Internet
-Via Host
-
Gerenciamento de múltiplas antenas
-Tipicamente 4 antenas por leitor
-Quantidade de antenas que podem ser consultadas ou multiplexadas
-
Adaptação às condições das antenas
- Ajuste automático
-
Interface com middlewares de mercado
- Interfaces digitais de entrada e saída para sensores externos e circuitos de controle
3.2.2 Considerações sobre antenas de
leitores
Em um sistema RFID , as antenas dos leitores são geralmente o ponto de partida para o seu projeto. Para aplicações HF de baixo alcance (10 cm) e baixa emissão de energia como sistemas de controle de acesso , as antenas tendem a ser integradas com os leitores.Para sistemas HF de maior alcance ( de 10 cm a 1 metro) e UHFs (mas que 3 metros de alcance), a antena é quase sempre externa , e conectada ao leitor através de um cabo coaxial protegido e de impedância compatível.
Mesmo que antenas sejam compradas como produtos fechados , às vezes é necessário que sejam projetadas versões específicas para determinadas aplicações.Os princípios de funcionamento das antenas e seus respectivos processos de construção são radicalmente diferentes nas versões LF e HF do que na versão UHF. Na realidade , sistemas como HF não utilizam antenas na prática , pois eles trabalham no modo near field , onde não há propagação eletromagnética.
A maior parte das antenas RFID precisam ser ajustadas para a ressonância da freqüência de operação. Isso as deixam propensas à diversos efeitos externos , que podem impactar seriamente na distância de comunicação caso haja algum desvio (mesmo que pequeno) neste ajuste.As causa podem variar dependendo da freqüência de operação e podem ser originadas a partir de algumas das razões descritas abaixo:
-
Variações RF
- Perdas devido à proximidade à metais
- Perdas em cabos da antena
- Sinais atenuados
- Proximidade à outras antenas de leitores
-Variações no ambiente
- Efeitos harmônicos
- Interferência com outras fontes RF
- Reflexões de sinais
- Comunicações cruzadas
O problema do desajuste da antena causado por algum dos problemas mencionados acima pode ser corrigido por circuitos de ajustes automáticos que trabalham com o retorno dos parâmetros de ajuste de ressonância da antena. Esse artifício garante estabilidade e performance máxima para a freqüência selecionada.
Em relação a performance , os projetos que envolvam antenas para comunicações à distância devem levar em conta os seguintes parâmetros :
- Faixa de freqüência de operação
- Impedância (tipicamente 50 ohms)
- Máxima potência permitida
- Ganho
- Padrão de radiação (polarização XY , circular , etc.)
Esses são os elementos chaves que permitem maior potência e padrões mais robustos de sinais (zonas de leitura) RF , que são por sua vez afetados pela eficiência e o tipo de sincronismo (indutivo , por radiação) utilizados entre o leitor e o tag.
Por fim , seguem alguns formatos de antenas que podem ser utilizados em sistemas RFID:
- Polarizadas circularmente
- Adaptadas
- Omni-direcionadas
- Direcionadas
- Dipolo ou Multipolo
- Polarizadas linearmente
Além de tags e leitores , os fabricantes de equipamentos destinados a RFID desenvolvem alguns acessórios que facilitam a operação e gerenciamento destes sistemas. Um exemplo são os leitores manuais RFID , utilizados para intervenções manuais quando um tag precisa ser checado , ou mesmo atualizado off-line. Séries deste tipo de produto são encontrados para HF , porém no caso de UHF há produtos baseados em dispositivos PDA que são comercialmente disponíveis , porém não classificados como produtos de série.
Uma outra espécie de produto para sistemas RFID são as impressoras de etiquetas , que são projetadas para programar dados nos tags adesivos , assim que estes passam através do dispositivo de impressão do equipamento.A impressora possui um leitor VHF ou UHF (ou ambos) embutido , capaz de inicialmente de processar uma funcionalidade básica no tag, como checá-lo , e , caso haja falha , imprimir uma marca de rejeição na superfície do papel do tag. Os tags precisam ter formatos corretos para que seja possível utilizar a impressora.Em geral , as impressoras de etiquetas RFID possuem capacidade para imprimir e programar uma média de 1,5 etiquetas por segundo , dependendo do tamanho do papel utilizado.
|
Capítulo 4 |
Legislação , Padronização Vigente e Classes em RFID |
4.1
Legislação Referente à Utilização de RFID
4.1.1 O papel da Legislação e da
Regulação de Faixas
Por seu valor de comunicação , a faixa eletromagnética é um recurso valioso que é controlado por governos em todo o mundo. Em algumas freqüências , a transmissão de ondas eletromagnéticas tem um efeito muito limitado / localizado.A luz visível , por exemplo, é facilmente atenuada e bloqueada. Entretanto , ondas de rádio são consideravelmente mais penetrantes – um transmissor em um edifício/cidade/país pode ter um impacto significante na operação de um receptor em um outro edifício/cidade/país. Por isso , a transmissão de ondas de rádio são em geral controladas rigorosamente por tratados nacionais e internacionais. Estes especificam amplitudes , freqüências , mecanismos de comunicação e aplicações que são permitidas através de um processo conhecido como licenciamento de faixas.
4.1.2 Conceituação de Legislação em
Sistemas RFID
Há um número de faixas de freqüência nas quais a operação de RFID é permitida. Pelo fato de governos nacionais terem historicamente sidos responsáveis pelo licenciamento de faixas , diferentes países geralmente tem diferentes alocações de freqüência. Governos por tudo o mundo têm trabalhado por diversos anos para harmonizar suas alocações de faixas , e esse trabalho , inevitavelmente , deve ter continuidade. Entretanto , a situação atual referente ao RFID é que na maior parte das regiões pode-se usar um sistema RFID nas faixas LH , HF ou UHF. As operações LF e HF são muito similares nas diversas regiões em que são usadas , porém a operação UHF varia de região para região. Essas diferenças estão relacionadas com as freqüências específicas e níveis de energia / potência que são permitidos , a velocidade em que a comunicação pode ocorrer , a faixa de utilização em que uma banda é compartilhada , e finalmente com as formas que os compartilhamentos são aplicados.
Muitos governos reconhecem o potencial de utilização de sistemas RFID , e o valor da harmonização de sistemas de rádio-comunicação em geral ; e como resultado estão trabalhando ativamente para assegurarem-se que uma determinada faixa alocada seja suficiente para sua região e também que diferenças entre diferentes regiões sejam minimizadas (ou se possível , eliminadas).
4.1.3 Legislações Específicas nas
Diversas Faixas Eletromagnéticas
A seguir , serão brevemente descritos as legislações específicas para cada faixa eletromagnética que pode ser utilizada em um sistema RFID:
-
Legislação
Específica em LF
125 – 134 kHz
Estas freqüências estão disponíveis para utilização em sistemas RFID na Europa , América do Norte e Japão.
-
Legislação
Específica em HF
13,56 MHz
Esta freqüência está disponível para utilização em sistemas RFID na Europa , América do Norte , Austrália e Japão em níveis de energia muito similares.
-
Legislação
Específica em UHF(Não-Microondas)
865,6 – 867,6 MHz
Trata-se de um rascunho à uma recomendação complementar à banda Européia entre 869,4 e 869,65 MHz que permite transmissões de , no máximo , 2W ERP (equivalente a 3,2W EIRP) usando dez canais de 200 kHz. Este rascunho também permite transmissões de até 0,1W ERP entre 865 e 865,6 MHz , e de até 0,5W ERP entre 867,6 e 868,0 MHz .Entretanto , estas alocações são improváveis para utilização prática de RFID.
869,4 – 869,65 MHz
Atualmente esta é uma alocação não-licenciada muito pequena (250 kHz) para a Europa , que deve ser usada por RFID (em conjunto com outras aplicações) em até no máximo 0,5W ERP. Tem sido utilizada por alguns sistemas RFID , porém a performance é limitada.
902 – 928 MHz
Banda não-licenciada disponível para utilização na América em sistemas desenvolvidos para transmissão de propagação de faixas de até 4W EIRP. Esta banda deve ser compartilhada com outros (não-RFID) usuários observando-se as mesmas regras de saltos de freqüência , como em sistemas de rede wireless.
918-926 MHz
Alocação disponível para RFID na Austrália , de até 1W EIRP.
950-956 MHz
Alocação potencial para RFID no Japão , seguindo à Comissão de Serviço de Telefonia Móvel Digital Pessoal de março de 2002. O Ministério de Gerenciamento Público , Assuntos Domésticos , Correios e Telecomunicações Japonês planeja estudar a viabilidade de utilizar esta banda para RFID e determinar a regulamentação necessária do uso dela nos próximos 18 meses ou mais. Estas regulamentações (as quais devem ser reservadas exclusivamente para RFID) possivelmente devem ser adotadas em Março de 2005.
-
Legislação
Específica em UHF(Microondas)
2,45 GHz
Banda não-licenciada disponível na maior parte das regiões do mundo em sistemas desenvolvidos para transmissão de propagação de faixas , embora os detalhes de utilização variam de região para região. Transmissões de até 4W EIRP são tipicamente permitidas (1W EIRP no Japão).Essa banda é utilizada pelo IEEE 802.11b e 802.11g , referentes a sistemas de rede wireless e sistemas de comunicação Bluetooth , entre outros.
4.1.4 Operações Fora da Faixa Alocada
Em muitas jurisdições pode ser possível obter permissões especiais dos reguladores de faixas de rádio-frequência para que se possa utilizar equipamentos que operem fora da legislação dominante.Por exemplo , o teste e o desenvolvimento de novas formas de equipamentos RFID , ou a utilização temporária de um equipamento RFID em não conformidade , ou até em avaliações caso a caso. Há diversos fatores que devem ser levados em conta em algumas circunstâncias , como a localidade do equipamento a ser desenvolvido e o potencial de interferência com usuários legítimos da faixa.
Esta abordagem tem sido utilizada em algumas companhias na Europa a fim de iniciar seus RFID trials com equipamentos em conformidade com a legislação Norte-Americana . Nestes casos , o uso antecipado de equipamentos em não-conformidade está situado dentro um período limitado e a operação do equipamento pode até ser modificada para minimizar a chance de se causar interferência.
4.2
Padronizações e Normas Estabelecidas para RFID
4.2.1 O papel dos Padrões na Indústria
RFID
Tradicionalmente , a indústria RFID tem sido conduzida por diversas áreas de aplicações verticais.Neste ambiente , é muito apropriado que diversos fornecedores de tecnologia desenvolvam produtos baseados em RFID que vão de encontro com a percepção do que o mercado necessita , sem nenhuma referência particular com os produtos oferecidos por seus concorrentes. Ao mesmo tempo , é esperado que seus produtos e sistemas devam estar em conformidade com a legislação que é aplicada na região em que eles operem.
Entretanto , a falta de padronização que acabou acontecendo em virtude de como os sistemas RFID foram sido construídos nos últimos anos fez com que surgisse uma barreira para as mais diversas adoções da tecnologia. Muitas aplicações requerem a integração de sistemas RFID de diversos fornecedores e/ou sistemas RFID de diferentes regiões. Por esta razão , nos últimos anos surgiram diversas tentativas de se criarem especificações que possam padronizar vários aspectos da operação de um sistema RFID.
4.2.2 Normas e Padrões Estabelecidos para
RFID
A seguir , serão relatados os padrões relevantes ao RFID que foram propostos por diversos segmentos da indústria.
1) EAN.UCC
A iniciativa GTAG (Global Tag) foi iniciada juntamente pela EAN International e o UCC (Uniform Code Council) em 2000. Eles reconheceram que a indústria RFID estava muito fragmentada para servir às necessidades de sua comunidade global de usuários.
O programa GTAG foi projetado para permitir à ambos soluções simples e desenvolvimentos apropriados para padrões de RFID baseados em processos comerciais oficiais.Esses padrões abrangem tecnologia RFID UHF (incluindo interface aérea) e também formatos de dados , baseados em consensos de processos de negócios da EAN.UCC e em como eles podem ser melhorados.
As considerações referentes à interface aérea no GTAG foram , em seguida , unidas com a especificação ISO 18000 – Parte 6 , que será discutida adiante.
2) ISO / IEC JT1 / SC17
A organização ISO (International Standards Organisation) está atualmente trabalhando com a IEC (International Electrotechnical Comission) para direcionar a padronização de Cartões de Identificação e dispositivos similares. Esta atividade conjunta está sendo assumida pelo JTC1/ SC17 (Joint Technical Committee 1 , Sub-committee 17). SC17 inclui em seu escopo as normas 10536 , 15693 , 14443.
ISO / IEC 10536
Cartões de Identificação –
Circuitos Integrados de Cartões Sem Contato
Essa norma descreve os parâmetros de proximidade da utilização de cartões de identificação (smart identification cards) , com uma faixa típica de 7 – 15 cm. , utilizando RFID a 13,56MHz.Esta norma está dividida em quatro partes:
Parte 1. Características Físicas
Parte 2. Dimensões e Localidades de Áreas de Operação e Interação
Parte 3. Sinais Elétricos e Procedimentos de Inicialização
Parte 4. Respostas à Inicialização e Protocolos de Transmissão
ISO / IEC 14443
Cartões de Identificação –
Circuitos Integrados de Cartões de Aproximação
Essa norma descreve os parâmetros de proximidade da utilização de cartões de identificação (smart identification cards) , com uma faixa típica de 7 – 15 cm. , utilizando RFID a 13,56MHz.Há quatro partes desta norma:
Parte 1. Características Físicas
Parte 2. Potência Relativa à Rádio-Frequência e Interface de Sinal
Parte 3. Inicialização e Anti-colisão
Parte 4. Protocolos de Transmissão
ISO / IEC 15693
Circuitos Integrados de
Cartões Sem Contato – Cartões de Média Distância
Essa norma descreve os parâmetros de utilização de cartões de identificação (smart identification cards) que além de não contarem com contato em sua operação , operam em uma distância maior , com uma faixa típica de até 1 metro , utilizando RFID a 13,56MHz.Esses cartões são também conhecidos como vicinity cards (cartões de “vizinhança”).Há quatro partes desta norma:
Parte 1. Características Físicas
Parte 2. Interface Aérea e Inicialização
Parte 3. Protocolos
Parte 4. Comandos estendidos e Funcionalidades de Segurança
3) ISO / IEC JT1 / SC31 / WG4
A Organização ISO está também trabalhando com o IEC para estabelecer uma padronização de Identificação Automática e Técnicas de Captura de Dados. Esta atividade conjunta está sendo assumida pelo JTC1 / SC31(Join Technical Committee 1, Sub-committee 31). Uma das áreas de consideração do SC31 é a do uso de RFID para Gerenciamento de Itens , que por sua vez está sendo assumido pelo SC31 / WG4 (workgroup 4). SC31 / WG4 inclui em seu escopo as normas 15961 , 15962 , 15963 , 18000 e 18001.
ISO / IEC 15961
RFID para Gerenciamento de
Itens – Protocolo de Dados:Interface de Aplicação
(Previamente nomeada como “RFID para Gerenciamento de Itens – Comandos Funcionais de Tags e Outras Características de Sintaxe”,porém o nome foi alterado em Maio de 2003)
Esta norma define comandos genéricos e características de sintaxe (por exemplo : tipos de tag , formatos de armazenamento de dados , esquemas de compressão , etc.) , independentemente do meio de transmissão e dos protocolos de interface aérea. É pretendido que seja um companhia à norma 15962 , a qual provê o protocolo global de manipulação de dados.
A norma 15961 irá compreender uma super coleção de todos os comandos funcionais e outras características de sintaxe apropriadas para Gerenciamento de Itens em RFID. Os comandos funcionais da norma 15961 correspondem à um nível maior de abstração em relação à série de normas 18000 da ISO , a fim de habilitar regras de manipulação de dados independentemente do nível mais básico de implementação.
ISO / IEC 15962
RFID para Gerenciamento de
Itens – Protocolo:Regras de Codificação de Dados e Funções Lógicas de Memória
(Previamente nomeada como “RFID para Gerenciamento de Itens – Sintaxe de Dados, porém o nome foi alterado em Maio de 2003)
Esta norma especifica as interfaces de procedimento utilizadas para exportar informações em um sistema RFID destinado a gerenciamento de itens. O protocolo estabelecido nesta norma garante o formato correto dos dados, a estrutura dos comandos e o processamento de erros em um sistema RFID.
ISO / IEC 15963
RFID para Gerenciamento de
Itens – Identificação Única do Tag RF
Esta norma especifica a numeração do sistema , o procedimento de registro e o uso de identificadores únicos em tags RFID. Há duas partes: a Parte 1 abrange o sistema de numeração enquanto a Parte 2 diz respeito ao procedimento de registro e à orientação de gerenciamento e regras.
Esta norma é projetada para envolver três aspectos:
1. O rastreamento do próprio circuito integrado para controle de qualidade em seu processo de fabricação
2. O rastreamento do tag RF durante o processo de fabricação e durante sua vida útil nas aplicações em que é utilizado
3. Anti-colisão de múltiplos tags no campo de alcance de leitura
ISO / IEC 18000
Normas para Interface
Aérea em Sistemas RFID
O conjunto de normas ISO 18000 disponibiliza uma estrutura de protocolos de comunicação comuns para uso internacional de RFID , e , quando possível , para determinar o uso de mesmos protocolos em diferentes freqüências a fim de minimizar os problemas de migração e para prover um modelo de gerenciamento de sistemas e controlar a troca de informações ao máximo.
As especificações ISO 18000 estão atualmente divididas em sete partes , conforme descrito na tabela 4.1. A parte 1 descreve a arquitetura sistêmica conceitual para RFID de gerenciamento de itens e define um conjunto de parâmetros que são necessários (em qualquer freqüência) para evitar a ocorrência de conflitos ou interferências com outros sistemas RFID , estabelecer um grau maior de interoperabilidade em aplicações reais e facilitar a integração com sistemas legados. As partes seguintes desta norma disponibilizam definições específicas para cada uma das freqüências RFID oficiais , e quando apropriado , promovem definições regionais baseadas em características geográficas.
|
Partes
da Norma ISO / IEC 18000 |
|
|
Parte
1 |
Parâmetros Genéricos para Interface Aérea de Comunicação para Freqüências Globais Oficiais |
|
Parte 2 |
Parâmetros para Interface Aérea de Comunicação Situada até 125kHz |
|
Parte 3 |
Parâmetros para Interface Aérea de Comunicação Situada em 13,56MHz |
|
Parte 4 |
Parâmetros para Interface Aérea de Comunicação Situada em 2,45GHz |
|
Parte
5 |
Parâmetros para Interface Aérea de Comunicação Situada em 5,8GHz (Posteriormente retirado devido à falta de aceitação global) |
|
Parte 6 |
Parâmetros para Interface Aérea de Comunicação Situada entre 860 – 930 MHz |
|
Parte
7 |
Parâmetros para Interface Aérea de Comunicação Situada em 433MHz (Submissão Posterior) |
Tabela 4.1:Divisão
em 7 partes da Norma ISO / IEC 18000
Fonte: Auto-Id Center
Há duas partes particularmente interessantes : a Parte 3 e a Parte 6.A Parte 3 possui dois modos de operação distintos , que não possuem interoperabilidade , tendo sido projetadas para não conflitar / interferir entre si. O Modo 1 é baseado na norma ISO 15693 com melhorias adicionais , enquanto que o Modo 2 define uma nova interface de alta velocidade. Por sua vez , a Parte 6 define também dois modos de operação , conhecidos como A e B.
O conjunto de normas ISO / IEC trata apenas do protocolo de interface aérea , não abrangendo aspectos relacionados ao conteúdo de dados ou a implementação física dos leitores e tags . Estas normas não especificam o conteúdo de dados ou sua estrutura , tratando apenas dos aspectos relacionados ao seu transporte.
4) ISO / IEC JT1 / SC31 / WG3
O JTC1 / SC31 / WG3 (Joint Technical Committee ,Sub-committee 31, workgroup 3) trata de assuntos relacionados à conformidades.
ISO / IEC 18046
Tag RF e Métodos de Teste
de Validação de Performance
Atualmente em versão draft. O relatório draft técnico é esperado para o fim de 2004.
ISO / IEC 18047
Métodos de Teste de
Conformidade em Dispositivos RFID
Esta norma está dividida em várias partes , seguindo a segmentação da norma ISO / IEC 18000. Atualmente as várias partes estão descritas em um formato draft direcionadas em seus diversos comitês , com a exceção da Parte 3 (13,56MHz) , que já progrediu para o estágio de Draft Preliminar.
4.3
Classes RFID
4.3.1 A Estrutura de Classes
Neste tópico será descrito a estrutura de classes RFID. Esta estrutura foi planejada e concebida por diversos especialistas do Auto-ID Center , que é o Centro especializado em desenvolver tecnologias e padrões relacionados à sistemas e redes que tenham como objetivo propiciar auto-identificação , sendo que a tecnologia RFID aliada aos conceitos das Redes EPCs é atualmente um dos principais focos de estudo e projeto do Centro.
Esta estrutura surgiu em meio à diversas discussões e debates entre o Auto-ID Center e diversas companhias , entre elas a Alien Technology . Ela foi inicialmente articulada em um trabalho preliminar da Diretoria de Tecnologia da Alien e ainda passa por um processo de evolução . Enquanto esta estrutura ainda não captura todos os aspectos evolutivos que os tags possam sofrer , ela ainda assim pode servir como uma referência útil para o estudo e a compreensão do comportamento dos tags RFID. É importante ressaltar que essa estrutura nasceu com a finalidade de propor uma classificação padronizada dos tags , mas que ao mesmo tempo trabalha em conjunto com os outros padrões e normas citados anteriormente , ou seja , complementando-os para uma referência mais robusta no que diz respeito à tecnologia RFID.
A figura 4.1 mostra a Estrutura de Classes RFID utilizada como referência atualmente.
Figura 4.1 Classes em RFID Fonte: Auto-Id Center
Os tags das Classes 0 e I possuem capacidades básicas.A Classe II representa uma adição de funcionalidades , como encriptação ou memória para tags passivos.As Classes III , IV e V representam um incremento adicional de energia , em vários níveis , como um recurso. Tags da Classe III utilizam baterias apenas para energizar a parte lógica do circuito. Tags da Classe IV são tags ativos.Dispositivos de Classe V tem energia suficiente para energizar outros tags.
A Estrutura de Classes apresentada acima é independente da faixa de freqüências, ou seja , deve valer para as banda HF e UHF ; assim como para a banda LF quando outros tipos de protocolos forem estabelecidos para ela.
4.3.2 Princípios de Modularidade de
Plataforma e Estados Padrões
A proposta de divisão em Classes contempla o conceito de que os protocolos para todas as espécies de tags são modulares , e que podem ser construídos em diversas plataformas.Para isso , três princípios são estipulados:
- Funcionalidades e Modos Adicionais podem ser acessados através de comandos extras aos existentes no protocolo RFID. Por exemplo , se um tag possui memória adicional , podem haver comandos de escrita e leitura adicionais aos existentes nos protocolos das Classes 0 e I. De forma similar , se um tag pode operar no modo de banda larga , ele pode ser comandado para passar deste modo para outro modo contemplado dentro das Classe 0 ou I. Todos os comandos que acessem funcionalidades maiores devem ser comunicados caso haja sucesso (por exemplo , com um <ack>) , ou com um código de erro ( com um <nack> , por exemplo) ; auxiliando em processos de rastreamento e monitoramento.
- Todos os tags que são compatíveis com o Auto-Id Center devem operar no modo básico relacionado às Classes 0 e I por default(padrão). Em outras palavras , os tags devem operar em uma banda restrita , com o protocolo mais básico no modo default. Deve existir também um Modo Gobal de Ativação Default , que retornam os tags para o modo default. Isso pode ser , por exemplo , uma simples pausa na energia ou na modulação (ou em ambas). Por exemplo , um tag da Classe IV operando em banda larga precisará operar como um tag de Classe 0 ou I por default. Ele passará a operar com capacidades relacionadas à banda larga apenas após ser comandado para tal.
- Em caso de falha de uma função ou um modo avançados , o tag deve ser projetado para um modo de segurança que o leva à uma Classe mais baixa. Isso faz com que o tag tenha Tolerância à Falhas . Por exemplo , quando um tag semi-passivo perde sua fonte de energia , ele deve atuar como uma tag passivo. Quando um tag ativo perde energia , ele deve-se “tornar” um tag semi-passivo. Isso faz com que a falha seja o mais transparente possível , sendo uma vantagem da abordagem modular.
Essa estratégia estabelece um padrão comum para operação em modo default no início das transações , sendo que todos os tags podem retornar à este modo à qualquer momento. Esta abordagem preocupa-se também com uma percepção eficiente. Um leitor que é desconhecido à alguns tags em uma determinada vizinhança é incapaz de aproveitar suas funcionalidades.A percepção aos tags significa um passo muito importante em aplicações e transações com que os utilizem. Quando se pensa nas redes EPC , por exemplo, deve-se garantir que o Código Eletrônico seja completamente perceptível. Pode haver , por exemplo , uma base de dados que captura as capacidades adicionais dos tags em uma determinada população e que então permita ao leitor transacionar informações com o tag.
Aplicações que façam parte da rede EPC podem detectar uma capacidade específica de um tag e , a partir daí , disparar comandos específicos reconhecidos como pertencentes a este , estabelecendo então uma comunicação direcionada para determinados fins.Para que isso funcione com a melhor performance possível , deve-se garantir que a percepção ao tag funcione de forma estável e confiável.
Em suma , a partir do princípio que um conjunto de tags heterogêneos operem simultaneamente , deve-se considerar um modo default de operação . Caso contrário , o leitor poderia ter que continuamente procurar outros modos de operação , com isso perdendo banda e aumentando o problema de colisões. Com um modo default , esta busca torna-se unificada e mais eficiente.
|
Capítulo 5 |
Especificações e Características da Codificação EPC |
5.1
Introdução à Tecnologia e Codificação EPC
Para falar sobre as Redes EPC é essencial que se inicie pelo detalhamento dos conceitos pertencentes à padronização e estruturação do código eletrônico , ou seja , do próprio EPC.
Como já citado , o Electronic Product Code (EPC) é um esquema de identificação universal de objetos físicos via tags RFID. Os dados EPC padrões consistem de um EPC (ou identificador EPC) , que identifica unicamente um objeto individual ; e de um Valor de Filtragem opcional quando necessário , para permitir uma leitura de tags EPC efetiva e eficiente.Em complemento à essa padronização de dados , certas classes de tags EPC irão permitir também dados definidos pelo usuário.A Padronização de Dados de Tags EPC (EPC Tag Data Standards) irá definir o tamanho e a posição desses dados , porém sem definir seu conteúdo.
O identificador EPC é um esquema baseado em meta-código , projetado para atender às necessidades de várias indústrias através do acomodamento , tanto dos esquemas de código existentes , quanto dos possíveis novos esquemas que possam ser definidos quando necessário.Os diversos esquemas de códigos são referenciados como Identificadores de Domínio , a fim de indicar que eles possibilitem identificação de objetos dentro de certos domínios , como uma indústria em particular ou mesmo um grupo de indústrias.Por isso , o Electronic Product Code representa uma família de esquemas (ou “namespaces”) e um significado para cada um deles , para fazer com que sejam reconhecidos com únicos dentro de todos os possíveis tags EPC compatíveis.Esses conceitos serão descritos neste capítulo.
Figura 5.1 Terminologia EPC Fonte: EPCglobal
Na versão atual do EPC (EPC Versão 1.1) , os esquemas de código incluem um Identificador Geral ,originalmente chamado de General Identifier (GID) , uma versão serial do EAN.UCC Global Trade Item Number (GTIN) , o EAN.UCC Serial Shipping Container Code (SSCC) , o EAN.UCC Global Location Number (GLN) , o EAN.UCC Global Returnable Asset Identifier (GRAI) e o EAN.UCC Global Individual Asset Identifier (GIAI).
Nos sub-capítulos seguintes , serão descritos a estrutura organizacional do EPC , além de tabelas e figuras que mostram seu uso recomendados.
O EPCglobal TAG Data Standard V1.1 R1.23 ,ou seja , a versão atual da padronização referente ao EPC , foi aprovada pelo órgão EAN.UCC com restrições que estão descritas na Seção 3.7 das Especificações do órgão.
5.2
Conceitos sobre Identidade
Para compreender melhor a estrutura geral dos Padrões de Dados de Tags EPC (EPC Tag Data Standards), é interessante distinguir três diferentes camadas de identificação , conforme mostra a figura 5.2 .
5.2 Namespaces de Identidade , Codificações e Realizações definidos Fonte: EPCglobal
Identidade Pura – a identidade associada com uma entidade lógica ou física específica, independente de qualquer veículo de codificação particular , como um tag RF , código de barras ou um campo de uma base de dados.Uma identidade pura é um nome ou número abstrato utilizado para identificar uma entidade.Uma identidade pura consiste da informação requerida para identificar unicamente uma entidade específica , e nada mais.A Identidade URI é uma representação de uma identidade pura como um Recurso Identificador Uniforme , originalmente chamado de Uniform Resource Identifier (URI). Uma URI é a representação de uma string de caracteres que é comumente utilizada na troca de dados de identificação entre componentes de software em um grande sistema .
Codificação – Uma identidade pura , juntamente com informações adicionais (como por exemplo um valor de filtragem) , traduzido para uma sintaxe específica , que tipicamente consiste de campos de valores de tamanhos específicos. Uma identidade pura deve possuir um certo número de possíveis codificações , como por exemplo código-de-barras , várias codificações de tags e várias codificações URI. Codificações devem também incorporar dados adicionais à identidade (como por exemplo valores de filtragem utilizados em algumas codificações), sendo que em cada caso o esquema de codificação especifica quais dados adicionais podem ser colocados.
Realização Física de uma Codificação – uma codificação traduzida em uma implementação concreta .Essa implementação deve ser apropriada para uma determinada máquina leitora que é utilizada na aplicação , como por exemplo um tipo específico de tag RF ou um campo específico de uma base de dados.Uma determinada codificação pode possuir várias possíveis realizações físicas.
Por exemplo , o formato SSCC(Serial Shipping Container Code) , que é definido pelo órgão EAN.UCC , é um exemplo de identidade pura.Um SSCC codificado no formato EPC-SSCC 96-bits é um exemplo de codificação. Essa codificação 96-bits , escrita em um tag RF , é um exemplo de realização física.
Um esquema de codificação particular pode implicitamente impor restrições na faixa de identidades que podem ser representadas utilizando tal codificação.Por exemplo , apenas 16.384 prefixos de companhias podem ser codificados no esquema SSCC 64-bits. Em geral , cada esquema de codificação especifica quais restrições são impostas na faixa de identidades que ele pode representar.
Inversamente , um esquema de codificação em particular pode acomodar valores que não são válidos em relação ao tipo de identidade pura adjacente , dessa forma requerendo uma restrição explícita. Por exemplo , a codificação EPC-SSCC 96-bits provê 24 bits para codificar um prefixo de companhia de 7 dígitos de comprimento.Em um campo de 24 bits, é possível codificar o número decimal 10.000.001 , que é maior do que 7 dígitos. Portanto , isso não representa um SSCC válido , sendo então proibido. Em geral , cada esquema de codificação especifica quais são os limites impostos no valor que deve aparecer em qualquer campo codificado.
5.2.1 Camada de Identidade Pura : Tipos
Genéricos
A versão atual dos Padrões de Dados de Tags EPC define um tipo genérico de identidade. O General Identifier (GID-96) é independente de qualquer esquema de identificação e de especificações conhecidas ou existentes.O General Identifier é composto de três campos: o Número Geral Diretor (General Manager Number) , a Classe de Objeto (Object Class) e o Número de Série (Serial Number).Codificações do GID incluem um quarto campo , o header , para garantir a unidade do namespace EPC.
O Número Geral Diretor (General Manager Number) identifica uma entidade organizacional (essencialmente uma companhia , uma direção ou outras organizações) que é responsável pela manutenção dos números dos campos subseqüentes – Classe do Objeto e Número de Série. A organização EPCglobal atribui o Número Geral Diretor à uma entidade , e garante que cada Número Geral Diretor seja único.
A Classe de Objeto (Object Class) é utilizada por uma entidade EPC gerenciada para identificar uma classe ou “tipo” de objeto. Esses números de classes de objetos devem ser únicos dentro de cada um dos domínios de Números Gerais Diretores , ou seja , cada organização deve possuir números únicos para cada tipo de objeto que ela fabrique ou manipule. Exemplos de classes de objetos incluem os diferentes tipos de embalagens para armazenamento e estoque de bens de consumo , ou cada um dos diferentes itens da linha de produtos de uma determinada empresa , assim como diferentes estruturas em um sistema de auto-estrada , como sinalizações rodoviárias , postes de iluminação e pontes, onde a entidade gerenciadora pode ser um Estado ou País.
Finalmente , o Número de Série (Serial Number) deve ser único dentro de cada classe de objetos. Ou seja , a entidade gerenciadora é responsável por atribuir um único e não repetido número de série para cada instância dentro de uma classe de objetos.
5.2.2 Camada de Identidade Pura :
Sistemas de Identificação EAN.UCC
A versão atual dos Padrões de Dados de Tags EPC define cinco tipos de identificação EPC derivados da família de sistemas de códigos de produto EAN.UCC , que serão descritos nos sub-capítulos seguintes.
Os sistemas de códigos EAN.UCC possuem uma estrutura comum , que consiste de um número fixo de dígitos decimais que codificam a identidade , e também um “dígito de checagem” adicional que é computado algoritmicamente através dos outros dígitos. Entre os dígitos de não checagem há uma divisão implícita em dois campos: um Prefixo da Companhia (Company Prefix) atribuído pela EAN ou UCC à uma entidade gerenciadora , e os dígitos restantes , que são atribuídos pela entidade gerenciadora.(Os dígitos separados do Prefixo da Companhia são chamados por um nome diferente em cada um dos sistemas de codificação da EAN.UCC). O número de dígitos decimais no Prefixo da Companhia varia de 6 até 12 , dependendo do prefixo atribuído. Então , o número de dígitos restantes varia inversamente , e para isso o número total de dígitos é fixado especificamente para cada sistema de códigos da EAN.UCC.
As recomendações da EAN.UCC para a codificação de sistemas de identificação no caso dos códigos de barras , assim como em seu uso associado com softwares de processamento de dados , estipula que os dígitos compreendidos (como em qualquer sistema EAN.UCC) devem sempre serem processados como uma unidade , e não divididos em campos individuais.Entretanto , essa recomendação não é apropriada dentro dos conceitos das redes EPC , já que o fato de dividir o código entre a parte destinada à entidade gerenciadora (o Prefixo da Companhia nos sistemas EAN.UCC) e a parte que é gerenciada pela entidade gerenciadora (o restante) é essencial para prover a funcionalidade do ONS (Object Name Service , que será descrito no próximo capítulo). Além disso, acredita-se que o fato de se distinguir o Prefixo da Companhia seja útil para filtrar ou prover segurança de acesso para dados derivados do EPC. Por isso, as codificações EPC para códigos da EAN.UCC especificam essas diferenças acima mencionadas das seguintes formas:
- As codificações EPC carregam uma divisão explícita entre o Prefixo da Companhia e os dígitos restantes , que devem ser cada qual codificado no formato binário.Por isso , realizar a conversão da representação decimal tradicional dos sistemas de código da EAN.UCC e das codificações EPC requerem controles independentes em relação ao comprimento do Prefixo da Companhia.
- Codificações EPC não incluem o dígito de checagem.Por isso , realizar a conversão de uma codificação EPC para uma representação decimal tradicional de um código , requer que o dígito de checagem seja recalculado a partir dos outros dígitos.
Conforme citado anteriormente , há cinco tipos de codificações distintas na família de esquemas definidas pela EAN.UCC. São elas:
Serialized Global Trade Identification Number (SGTIN) – Complementa a codificação GTIN (que codifica classes de objeto) com a adição da serialização única para cada objeto.
Serial Shipping Container Code (SSCC) – Assim como o padrão SSCC tradicional , é usada na fase de transporte do produto até o ponto de venda.É serial e única para cada objeto.
Serialized Global Location Number (SGLN) – Representa a codificação padrão GLN. É usada para codificar locações físicas(docas,armazéns,etc.)em que os objetos se encontram.
Global Returnable Asset Identifier (GRAI) – É utilizado para identificar , em cada objeto , a qual classe ou tipo de ativo(para inventários , por exemplo)ele pertence.
Global Individual Asset Identifier (GIAI) – Assim como o padrão GIAI já existente , é utilizado para codificar a identificação individual e única de cada ativo (objeto).
Os esquemas de codificação citados acima possuem 2 categorias , uma de 64 bits e outra de 96 bits.A descrição de cada um desses esquemas será abordada no próximo subcapítulo , que falará sobre a camada de codificação à nível de bits para tags EPC.
5.3
Codificações em nível de bits para Tags EPC
A estrutura geral das codificações EPC em um tag é composta por uma string de bits (ou seja , uma representação binária) , que consiste de um header(cabeçalho) de tamanho variável seguido de uma série de campos numéricos , cujos tamanhos . estruturas e funções são completamente determinados pelo valor do header.
5.3.1 Headers
Como previamente descrito , o Header (Cabeçalho) define o tamanho total , o tipo de identificação e a estrutura de uma Codificação de um tag EPC , incluindo seu Valor de Filtragem , se houver. O header tem tamanho variável , sendo formado por um conjunto de bits em seqüência (uma string), onde um valor ’0’ em cada posição (a partir da primeira) indica que a string deve continuar sendo lida até que um valor ‘1’ apareça , para que aí então seja determinado seu tamanho mínimo. Ou seja , bits ‘0’ em seqüência são reservados para determinar o tamanho do header. Levando-se em consideração que os headers podem possuir apenas 2 ou 8 bits , quando ele possuir 2 , seus possíveis valores serão : 01 , 10 e 11 , não incluindo o valor 00 , pois este indicaria um header de tamanho mínimo de 3 bits. No caso dos de 8 bits , são possíveis 63 diferentes valores , sendo os dois primeiros sempre 00 , além de que o valor 00000000 é reservado para headers maiores que 8 bits.
A atribuição dos valores do Header foi projetada tal que o tamanho do tag seja facilmente distinguido através da análise dos bits mais à esquerda (Preâmbulo)do Header. Além disso , esse método visa definir o mínimo de Preâmbulos por tamanho de tag possível, de preferência 1 ou no máximo 2 ou 3. Com isso , o objetivo futuro é o de se evitar , sempre que possível , que se utilize Preâmbulos que permitam muitos poucos valores de Headers. Em suma ,a proposta deste método de Preâmbulo-de-tamanho-de-Tag é a de que os leitores RFID possam facilmente determinar o tamanho do tag.
Os Headers definidos atualmente são tais que , define-se um tag de 64 bits quando os dois primeiros bits tem valor ‘0’ ou se os cinco primeiros bits tenham valor ‘00001’ ; caso contrário o Header indica que este é um tag de 96 bits. No futuro , Headers ainda não atribuídos devem o ser para tags deste e de outros tamanhos.
Certos preâmbulos não estão correntemente vinculados para um tamanho de tags em particular , para que se deixe em aberto a opção para tamanhos adicionais , especialmente maiores , que possam acomodar esquemas de códigos maiores como por exemplo o Unique ID (UID) , que está sendo proposto pelo Departamento de Defesa dos EUA.
Onze esquemas de codificação já estão definidos na versão atual do EPC Tag Data Standard , conforme mostra a tabela 5.1 a seguir:
|
Valor do Header
(binário) |
Tamanho
do Tag (bits) |
Esquema
de Codificação EPC |
|
01 |
64 |
[Esquema de 64 bits reservado] |
|
10 |
64 |
SGTIN-64 |
|
11 |
64 |
[Esquema de 64 bits reservado] |
|
0000 0001 0000 001x 0000 01xx |
na na na |
[1 esquema reservado] [2 esquemas reservados] [4 esquemas reservados] |
|
0000 1000 |
64 |
SSCC-64 |
|
0000 1001 |
64 |
GLN-64 |
|
0000 1010 |
64 |
GRAI-64 |
|
0000 1011 |
64 |
GIAI-64 |
|
0000 1100 ... 0000 1111 |
64 |
[4 esquemas de 64 bits reservados] |
|
0001 0000 ... 00101111 |
na |
[32 esquemas reservados] |
|
0011 0000 |
96 |
SGTIN-96 |
|
0011 0001 |
96 |
SSCC-96 |
|
0011 0010 |
96 |
GLN-96 |
|
0011 0011 |
96 |
GRAI-96 |
|
0011 0100 |
96 |
GIAI-96 |
|
0011 0101 |
96 |
GID-96 |
|
0011 0110 ... 0011 1111 |
96 |
[10 esquemas reservados de 96 bits] |
|
0000 0000 ... |
|
[Reservado para Headers futuros maiores que 8 bits] |
Tabela 5.1 Headers EPC Fonte: EPCglobal
5.3.2 Convenções de Notação
Na continuidade deste capítulo , os esquemas de codificação de tags serão descritos utilizando a notação mostrada na tabela 5.2.
|
|
Header |
Valor
de Filtragem |
Índice de Prefixo da Companhia |
Referência do
Item |
Número
de Série |
|
SGTIN-64 |
2 |
3 |
14 |
20 |
25 |
|
10 (Valor Binário) |
8 (Capacidade Decimal) |
16.383 (Capacidade Decimal) |
9 – 1.048.575 (Capacidade Decimal*) |
33.554.431 (Capacidade Decimal) |
*Capacidade
do campo de Referência do Item varia de acordo com o tamanho do campo do
Prefixo da Companhia
Tabela 5.2 Exemplo de
Convenção de Notação
Fonte: EPCglobal
A primeira coluna da tabela informa o nome formal da codificação. As colunas restantes especificam o layout de cada campo dentro dela. O campo da coluna mais à esquerda ocupa os bits mais significativos da codificação (esse é sempre o campo header) , e o campo da coluna mais à direita ocupa os bits menos significativos.Cada campo é um número inteiro não negativo , codificado em binário e possuindo um número específico de bits. Qualquer bit não utilizado (ou seja , bits não requeridos por um campo definido) estão explicitamente indicados na tabela , de modo que as colunas da tabela estão concatenadas sem intervalos , para que então se forme a codificação binária.
Lendo coluna abaixo , a tabela indica o nome formal do campo , o número de bits utilizado para codificá-lo e o número de possíveis valores que são permitidos para ele. O número de possíveis valores no campo pode ser um limite especificado , ou simplesmente pelo número máximo de combinações distintas em função do número de bits reservado para o campo.
Em alguns casos , o número de valores possíveis de um campo depende do valor atribuído a outro.Em alguns casos , um faixa de capacidade decimal é mostrada.
No exemplo acima (tabela 5.2) , a capacidade decimal campo de Referência do Item depende do tamanho do campo de Prefixo da Companhia ; por isso a capacidade decimal é mostrada como uma faixa de valores. Onde um campo deve conter um valor específico (como o campo Header), a última linha da tabela especifica o valor específico ao invés do número de possíveis valores.
Algumas codificações possuem campos de tamanho variável.O texto que acompanha a tabela especifica como os limites do campo são determinados nesses casos.
Nos subcapítulos que se seguirão , além da tabela demonstrativa de cada esquema de codificação , é também mostrada uma descrição genérica de cada um deles e também uma descrição de cada campo da codificação.
5.3.3 General Identifier (GID-96)
O esquema de codificação General Identifier é definido para um EPC de 96 bits , sendo independente de qualquer convenção ou especificação existente. O General Identifier é composto de três campos: o Número Geral Diretor (General Manager Number) , a Classe de Objeto (Object Class) e o Número de Série (Serial Number). Codificações GID incluem um quarto campo , o header , para garantir a unicidade no namespace EPC , conforme mostra a tabela 5.3.
|
|
Header |
Número
Geral Diretor |
Classe
de Objeto |
Número
de Série |
|
GID-96 |
8 |
28 |
24 |
36 |
|
0011 0101 (Valor Binário) |
268.435.456 (Capacidade Decimal) |
16.777.216 (Capacidade Decimal) |
68.719.476.736 (Capacidade Decimal) |
Tabela 5.3
Esquema de Codificação GID-96
Fonte: EPCglobal
Número Geral Diretor (General Manager Number) - Identifica essencialmente uma companhia , direção ou organização ; que é a entidade responsável por manter os números dos campos subseqüentes – Classe de Objeto e Número de Série. A organização EPCglobal atribui o Número Geral Diretor à uma entidade , ao mesmo tempo garantindo que cada um destes números seja único.
Classe de Objeto (Object Class) - É utilizado por uma entidade gerenciadora EPC para identificar uma classe ou “tipo” de objeto. Esses números de classes dos objetos devem ser únicos para cada Número Geral Diretor. Por exemplo, uma Classe de Objeto pode ser uma parte de um componente em uma linha de montagem , ou cada tipo de embalagem distinta para um determinado produto.
Número de Série (Serial Number) – Também chamado de número serial , é único dentro de uma classe de objeto. Em outras palavras , a entidade gerenciadora é responsável por atribuir números seriais únicos e não repetidos para cada instância associada à cada código de Classe de Objeto.
5.3.4 Serialized Global Trade Item
Number (SGTIN)
O esquema de codificação EPC para SGTIN permite o compartilhamento do Sistema padrão EAN.UCC GTIN junto aos códigos de Números Seriais em tags EPC. Em todos os casos , o dígito de checagem não é codificado. Dois esquemas de codificação são especificados , o SGTIN-64 (64 bits) e SGTIN-96 (96 bits).
Na codificação SGTIN-64 , o número limitado de bits proíbe uma acomodação literal do GTIN. Como solução parcial , um Índice de Prefixo da Companhia é utilizado. Esse Índice , que pode ser acomodado em até 16.384 códigos , é atribuído a companhias que necessitam utilizar tags de 64 bits , em adição aos seus Prefixos de Companhia EAN.UCC existentes. Esse Índice é codificado em um tag no lugar do Prefixo da Companhia , sendo a seguir traduzido para o Prefixo da Companhia em níveis mais baixos dos componentes do sistema EPC (Leitor ou Savant). Enquanto isso significa que apenas um limitado número de Prefixos de Companhia possam ser representados em tags de 64 bits , esse é um passo transitório para acomodações por inteiro em 96 bits e demais esquemas de codificação.
5.3.4.1
SGTIN-64
O esquema SGTIN-64 inclui cinco campos: Header , Valor de Filtragem , Índice de Prefixo da Companhia , Referência do Item e Número de Série , como mostrado na tabela 5.4.
|
|
Header |
Valor
de Filtragem |
Índice de Prefixo da Companhia |
Referência do
Item |
Número de Série |
|
SGTIN-64 |
2 |
3 |
14 |
20 |
25 |
|
10 (Valor Binário) |
8 (Capacidade Decimal) |
16.383 (Capacidade Decimal) |
9 – 1.048.575 (Capacidade Decimal*) |
33.554.431 (Capacidade Decimal) |
*Capacidade
do campo de Referência do Item varia de acordo com o tamanho do campo do
Prefixo da Companhia
Tabela 5.4 Esquema de
Codificação SGTIN-64
Fonte: EPCglobal
Header – Possui 2 bits , sendo 10 seu valor binário.
Valor de Filtragem (Filter Value) – Não faz parte do esquema de identidade pura SGTIN , mas é uma dado adicional utilizado para filtragem rápida e pré-seleção de tipos logísticos básicos , como itens , blocos internos , caixas e pallets. Os Valores de Filtragem para 64 bits e 96 bits são os mesmos. As especificações normativas para Valores de Filtragem ainda não estão definidas até o momento ; a tabela 5.5 mostra um resumo não-normativo desses valores (apenas para ilustração).
|
Tipo |
Valor
Binário |
|
Outros |
xxx |
|
Item |
xxx |
|
Blocos Internos |
xxx |
|
Caixa |
xxx |
|
Carga / Pallet |
xxx |
|
Reservado |
xxx |
Tabela 5.5 Valores de Filtragem SGTIN (Não-normativos) Fonte: EPCglobal
Índice de Prefixo da Companhia (Company Prefix Index) – Codifica o Prefixo de Companhia EAN.UCC. O valor desse campo não é o Prefixo em si , e sim um índice em um tabela que provê o Prefixo da Companhia assim como uma indicação do tamanho do Prefixo. A forma como um hardware ou software possa obter os conteúdos da tabela de tradução está especificada no documento Translation of 64-bit Tag Data Encoding Company Prefix Indices Into EAN.UCC Company Prefixes (EPCglobal).
Referência do Item (Item Reference) – Codifica o número do Item de Referência GTIN e do Dígito Indicador. O Dígito Indicador é combinado com o campo de Referência do Item da seguinte forma : Os zeros iniciais na referência do item são os significativos. Coloca-se o Dígito Indicador na posição disponível mais à esquerda dentro do campo. Falando-se em instâncias , 00235 é diferente de 235. Com o dígito indicador 1 , a combinação com 00235 resulta em 100235.A combinação resultante é tratada como um inteiro único , e codificada em binário para formar o campo de Referência do Item.
Número de Série (Serial Number) – Contem um número serial. A capacidade de 25 bits é limitada à 33.554.431 números , sendo menor que a capacidade prevista nas especificações de números seriais para sistemas EAN.UCC. Apenas números são permitidos.
5.3.4.2
SGTIN-96
Além do Header , o esquema SGTIN-96 é composto de cinco campos : o Valor de Filtragem , Partição , Prefixo da Companhia , Referência do Item e Número de Série , conforme mostra a tabela 5.6.
|
|
Header |
Valor
de Filtragem |
Partição |
Prefixo
da Companhia |
Referência do
Item |
Número
de Série |
|
SGTIN-96 |
8 |
3 |
3 |
20 - 40 |
24 – 4 |
38 |
|
0011 0000 (Valor Binário) |
8 (Capacidade Decimal) |
8 (Capacidade Decimal) |
999.999 – 999.999.999. 999 (Capacidade Decimal*) |
9.999.999 – 9 (Capacidade Decimal*) |
274.877.906.943 (Capacidade Decimal) |
*Capacidade do campo Prefixo da
Companhia/Referência do Item variam de acordo com o conteúdo do campo Partição
Tabela 5.6 Esquema de Codificação SGTIN-96 Fonte: EPCglobal
Header – Possui 8 bits , com o valor binário de 00110000.
Valor de Filtragem (Filter Value)– Não faz parte do esquema GTIN ou do identificador EPC , mas é utilizado para filtragem rápida e pré-seleção de tipos logísticos básicos , como itens , blocos internos , caixas e pallets. O Valor de Filtragem para GTIN de 64 ou 96 bits são os mesmos, conforme a tabela 5.5
Partição (Partition) – É a indicação de onde os números subseqüentes (Prefixo da Companhia e Referência do Item) estão divididos. Essa organização coincide com a estrutura GTIN da EAN.UCC , onde o Prefixo da Companhia adicionado com o número de Referência do Item (mais o Dígito Indicador único) totalizam 13 dígitos , já que o Prefixo da Companhia varia de 6 a 12 dígitos , e a Referência do Item (incluindo o Dígito Indicador único) de 7 a 1 dígito. Os valores disponíveis do campo Partição e os respectivos tamanhos dos campos Prefixo da Companhia e Referência do Item estão definidos na tabela 5.7.
|
Valor
de Partição (P) |
Prefixo
de Companhia |
Referência
do Item e Dígito Indicador |
||
|
|
Bits (M) |
Dígitos (L) |
Bits (N) |
Dígitos |
|
0 |
40 |
12 |
4 |
1 |
|
1 |
37 |
11 |
7 |
2 |
|
2 |
34 |
10 |
10 |
3 |
|
3 |
30 |
9 |
14 |
4 |
|
4 |
27 |
8 |
17 |
5 |
|
5 |
24 |
7 |
20 |
6 |
|
6 |
20 |
6 |
24 |
7 |
Tabela 5.7
Partições SGTIN-96 Fonte: EPCglobal
Prefixo da Companhia (Company Prefix) – Contém o formato literal (igual) ao do Prefixo
da Companhia da EAN.UCC.
Referência do Item (Item Reference)– Contém o formato literal do número de Referência do Item da EAN.UCC. O Dígito Indicador é combinado com o campo de Referência do Item da seguinte forma : Os zeros iniciais na referência do item são os significativos. Coloca-se o Dígito Indicador na posição disponível mais à esquerda dentro do campo. Falando-se em instâncias , 00235 é diferente de 235. Com o dígito indicador 1 , a combinação com 00235 resulta em 100235. A combinação resultante é tratada com um inteiro único , e codificada em binário para formar o campo de Referência do Item.
Número de Série(Serial Number) – Contem um número serial. A capacidade deste número serial é menor do que a capacidade máxima prevista nas especificações de números seriais para sistemas EAN.UCC , e apenas número são permitidos.
5.3.5 Serial Shipping Container Code
(SSCC)
O esquema de codificação EPC SSCC permite o acomodamento direto do padrão SSCC da EAN.UCC em tags EPC. Em todos os casos , o dígito de checagem não é codificado.Dois esquemas de codificação são especificados: SSCC-64 (64 bits) e SSCC-96(96 bits).
No EPC de 64 bits , o número limitado de bits proíbe uma acomodação direta do Prefixo da Companhia da EAN.UCC. Como uma solução parcial , um Índice de Prefixo da Companhia é utilizado. Esse Índice , que pode acomodar até 16.384 códigos, é atribuído a companhias que precisam utilizar tags de 64 bits , em adição aos seus Prefixos de Companhia existentes.Esse Índice é codificado no tag no lugar do Prefixo da Companhia , e é em seqüência traduzido para o Prefixo da Companhia em níveis mais baixos nos componentes de sistema da rede EPC (Leitor ou Savant). Enquanto isso significa que apenas um limitado número de Prefixos de Companhia possam ser representados em tags de 64 bits , esse é um passo transitório para acomodações por inteiro em 96 bits e demais esquemas de codificação.
5.3.5.1
SSCC-64
Além do Header , o esquema EPC SSCC-64 , é composto de três campos: o Valor de Filtragem , o Índice do Prefixo da Companhia e a Referência Serial , como mostra a tabela 5.8.
|
|
Header |
Valor
de Filtragem |
Índice de Prefixo da Companhia |
Referência
Serial |
|
SSCC-64 |
8 |
3 |
14 |
39 |
|
0000 1000 (Valor Binário) |
8 (Capacidade Decimal) |
16.383 (Capacidade Decimal) |
99.999 – 99.999.999.999 (Capacidade Decimal*) |
*Capacidade
do campo de Referência Serial varia de
acordo com o tamanho do Prefixo da Companhia
Tabela 5.8 Esquema de Codificação
SSCC-64 Fonte: EPCglobal
Header – Possui 8 bits , com valor binário de 00001000.
Valor de Filtragem(Filter Value) – Não é parte do identificador EPC ou SSCC , mas é utilizado para filtragem rápida e pré-seleção de tipos logísticos , como caixas e pallets. O Valor de Filtragem para os esquemas SSCC de 64 e 96 bits são os mesmos. As especificações normativas para os Valores de Filtragem não estão definidas até o momento.A tabela 5.9 mostra um resumo não-normativo para esses valores.
|
Tipo |
Valor
Binário |
|
Outros |
xxx |
|
Caixa |
xxx |
|
Carga / Pallet |
xxx |
|
Reservado |
xxx |
Tabela 5.9
Valores de Filtragem SSCC (Não-normativos)
Fonte: EPCglobal
Índice de Prefixo da Companhia (Company Prefix Index) – Codifica o Prefixo de Companhia EAN.UCC. O valor desse campo não é o Prefixo em si , e sim um índice em um tabela que provê o Prefixo da Companhia assim como uma indicação do tamanho do Prefixo. A forma como um hardware ou software possa obter os conteúdos da tabela de tradução está especificada no documento Translation of 64-bit Tag Data Encoding Company Prefix Indices Into EAN.UCC Company Prefixes (EPCglobal).
Referência Serial (Serial Reference) – É um número único para cada instância , que compreende a Referência Serial e o dígito de Extensão. O Dígito de Extensão é combinado com o campo de Referência Serial da seguinte forma: Os zeros iniciais da Referência Serial são os significativos. Coloca-se o Dígito de Extensão na posição disponível mais à esquerda dentro do campo. Falando-se em instâncias , 000042235 é diferente de 42235. Com o dígito de extensão de valor 1 , a combinação com 000042235 resulta em 1000042235.A combinação resultante é tratada como um inteiro único , e codificada em binário para formar o campo de Referência Serial. Para evitar referências seriais fora de especificação e grandes demais , elas não devem exceder a capacidade especificada nas especificações da EAN.UCC , que são (incluindo o dígito de extensão) de 9.999 para prefixos de companhia de 12 dígitos até 9.999.999.999 para prefixos de companhia de 6 dígitos.
5.3.5.2
SSCC-96
Além do Header , o esquema de codificação EPC SSCC-96 é composto de mais quatro campos : o Valor de Filtragem , Partição , Prefixo da Companhia e a Referência Serial , conforme mostra a tabela 5.10 abaixo:
|
|
Header |
Valor
de Filtragem |
Partição |
Prefixo
da Companhia |
Referência
Serial |
Não Alocado |
|
SSCC-96 |
8 |
3 |
3 |
20 - 40 |
37 - 17 |
25 |
|
0011 0001 (Valor Binário) |
8 (Capacidade Decimal) |
8 (Capacidade Decimal) |
999.999 – 999.999.999. 999 (Capacidade Decimal*) |
99.999.999.999 – 99.999 (Capacidade Decimal*) |
[Não Utilizado] |
*Capacidade do campo Prefixo da
Companhia/Referência Serial variam de acordo com o conteúdo do campo Partição
Tabela 5.10 Esquema de Codificação SSCC-96 Fonte: EPCglobal
Header – Possui 8 bits , com o valor binário de 00110001.
Valor de Filtragem (Filter Value)– Não faz parte do esquema SSCC ou do identificador EPC , mas é utilizado para filtragem rápida e pré-seleção de tipos logísticos básicos , como itens , blocos internos , caixas e pallets. O Valor de Filtragem para SSCC de 64 ou 96 bits são os mesmos, conforme a tabela 5.9.
Partição (Partition) – É a indicação de onde os números subseqüentes (Prefixo da Companhia e Referência Serial) estão divididos. Essa organização coincide com a estrutura SSCC da EAN.UCC , onde o Prefixo da Companhia adicionado com o número de Referência Serial (mais o Dígito de Extensão único) totalizam 17 dígitos , já que o Prefixo da Companhia varia de 6 a 12 dígitos , e a Referência Serial de 11 a 5 dígitos. A tabela 5.11 mostra os valores permitidos para o valor da partição e os comprimentos correspondentes do prefixo da companhia e da referência serial.
|
Valor
de Partição (P) |
Prefixo
da Companhia |
Referência
Serial e Dígito de Extensão |
||
|
|
Bits (M) |
Dígitos (L) |
Bits (N) |
Dígitos |
|
0 |
40 |
12 |
17 |
5 |
|
1 |
37 |
11 |
20 |
6 |
|
2 |
34 |
10 |
24 |
7 |
|
3 |
30 |
9 |
27 |
8 |
|
4 |
27 |
8 |
30 |
9 |
|
5 |
24 |
7 |
34 |
10 |
|
6 |
20 |
6 |
37 |
11 |
Tabela 5.11
Partições SSCC-96 Fonte: EPCglobal
Prefixo da Companhia (Company Prefix) – Contém o formato literal (igual) ao do Prefixo da Companhia da EAN.UCC.
Referência Serial (Serial Reference)– É um número único para cada instância , que compreende a Referência Serial e o dígito de Extensão. O Dígito de Extensão é combinado com o campo de Referência Serial da seguinte forma: Os zeros iniciais da Referência Serial são os significativos. Coloca-se o Dígito de Extensão na posição disponível mais à esquerda dentro do campo. Falando-se em instâncias , 000042235 é diferente de 42235. Com o dígito de extensão de valor 1 , a combinação com 000042235 resulta em 1000042235.A combinação resultante é tratada como um inteiro único , e codificada em binário para formar o campo de Referência Serial. Para evitar referências seriais fora de especificação e grandes demais , elas não devem exceder a capacidade especificada nas especificações da EAN.UCC , que são (incluindo o dígito de extensão) de 9.999 para prefixos de companhia de 12 dígitos até 9.999.999.999 para prefixos de companhia de 6 dígitos.
Não Alocado(Unallocated) – Não é utilizado. O campo deve conter zeros conforme a versão dessa especificação.
5.3.6 Serialized Global Location
Number (SGLN)
O esquema de codificação EPC para GLN permite o acomodamento direto do padrão GLN da EAN.UCC em tags EPC. O campo de número serial não é utilizado.Em todos os casos , o dígito de checagem não é codificado. Dois esquemas de codificação são especificados : SGLN-64 (64 bits) e SGLN-96 (96 bits).
Na codificação SGLN-64 , o número limitado de bits proíbe a acomodação direta do padrão GLN. Como uma solução parcial , um Índice de Prefixo da Companhia é utilizado. Esse índice , que pode acomodar até 16.384 códigos , é atribuído a companhias que necessitam utilizar tags de 64 bits , em adição ao seus Prefixos de Companhia EAN.UCC existentes. Esse índice é codificado em um tag no lugar Prefixo da Companhia , e é em seqüência traduzido para o Prefixo da Companhia em níveis mais baixos dos componentes de sistema da rede EPC (Leitor ou Savant).
Enquanto isso representa um limitado número de Prefixos de Companhia que possam ser representados em tags de 64 bits , esse é um passo transitório para a acomodação total de esquemas de 96 bits e demais esquemas.
5.3.6.1
SGLN-64
O esquema de codificação SGLN-64 inclui quatro campos além do Header : Valor de Filtragem , Índice de Prefixo da Companhia , Referência da Locação e Número de Série , conforme mostra a tabela 5.12.
|
|
Header |
Valor
de Filtragem |
Índice de Prefixo da Companhia |
Referência
da Locação |
Número
de
Série |
|
SGLN-64 |
8 |
3 |
14 |
20 |
19 |
|
0000 1001 (Valor Binário) |
8 (Capacidade Decimal) |
16.383 (Capacidade Decimal) |
999.999 – 0 (Capacidade Decimal*) |
524.288 (Capacidade Decimal) [Não Utilizado] |
*Capacidade
do campo Referência da Locação varia de
acordo com o tamanho do Prefixo da Companhia
Tabela 5.12 Esquema de Codificação
SGLN-64 Fonte: EPCglobal
Header – Possui 8 bits , com valor binário de 00001001.
Valor de Filtragem(Filter Value) – Não é parte da identidade pura SLGN , mas representa dados adicionais utilizados para filtragem rápida e pré-seleção de tipos básicos de posicionamento(físico , etc.). O Valor de Filtragem para os esquemas SSCC de 64 e 96 bits são os mesmos. As especificações normativas para os Valores de Filtragem não estão definidas até o momento.A tabela 5.13 mostra um resumo não-normativo para esses valores.
|
Tipo |
Valor
Binário |
|
Outros |
xxx |
|
Posição Física |
xxx |
|
Reservado |
xxx |
Tabela 5.13
Valores de Filtragem SGLN (Não-normativos)
Fonte: EPCglobal
Índice de Prefixo da Companhia (Company Prefix Index) – Codifica o Prefixo de Companhia EAN.UCC. O valor desse campo não é o Prefixo em si , e sim um índice em um tabela que provê o Prefixo da Companhia assim como uma indicação do tamanho do Prefixo. A forma como um hardware ou software possa obter os conteúdos da tabela de tradução está especificada no documento Translation of 64-bit Tag Data Encoding Company Prefix Indices Into EAN.UCC Company Prefixes (EPCglobal).
Referência da Locação(Location Reference) – Codifica a número de Referência da Locação GLN.
Número de Série(Serial Number) – Contêm um número serial.O campo de número serial é reservado não deve ser utilizado , até que comunidade EAN.UCC determine uma forma apropriada , se houver , de estendê-lo para GLN.
5.3.6.2
SGLN-96
Além do Header , o esquema de codificação SGLN-96 é composto de mais cinco campos: o Valor de Filtragem , Partição , Prefixo da Companhia , Referência da Locação e Número de Série , conforme mostra a tabela 5.14.
|
|
Header |
Valor
de Filtragem |
Partição |
Prefixo
da Companhia |
Referência
da Locação |
Número
de
Série |
|
|
SGLN-96 |
8 |
3 |
3 |
20 - 40 |
21 - 1 |
41 |
|
|
0011 0010 (Valor Binário) |
8 (Capacidade Decimal) |
8 (Capacidade Decimal) |
999.999 – 999.999.999. 999 (Capacidade Decimal*) |
999.999 – 0 (Capacidade Decimal*) |
2.199.023.255.552 (Capacidade Decimal) [Não Utilizado] |
||
*Capacidade dos campos Prefixo da
Companhia e Referência da Posição variam de acordo com o conteúdo do campo
Partição
Tabela 5.14 Esquema de Codificação
SGLN-96 Fonte: EPCglobal
Header – Possui 8 bits , com valor binário de 00110010
Valor de Filtragem(Filter Value) – Não faz parte dos identificadores EPC ou GLN , mas é utilizado para filtragem rápida e pré-seleção de tipos básicos de posicionamento(físico , etc.).Os Valores de Filtragem para GLN de 64 e 96 bits são os mesmos , conforme mostra a tabela 5.13.
Partição (Partition) – É a indicação de onde os números subseqüentes (Prefixo da Companhia e Referência da Posição) estão divididos. Essa organização coincide com a estrutura GLN da EAN.UCC , onde o Prefixo da Companhia adicionado ao número de Referência da Locação totalizam 12 dígitos , já que o Prefixo da Companhia varia de 6 a 12 dígitos , e a Referência da Locação de 6 a 0 dígito(s). Os valores disponíveis de Partição e os tamanhos correspondentes do Prefixo da Companhia e de Referência da Locação estão definidos na tabela 5.15.
|
Valor
de Partição (P) |
Prefixo
da Companhia |
Referência
da Locação |
||
|
|
Bits (M) |
Dígitos (L) |
Bits (N) |
Dígitos |
|
0 |
40 |
12 |
1 |
0 |
|
1 |
37 |
11 |
4 |
1 |
|
2 |
34 |
10 |
7 |
2 |
|
3 |
30 |
9 |
11 |
3 |
|
4 |
27 |
8 |
14 |
4 |
|
5 |
24 |
7 |
17 |
5 |
|
6 |
20 |
6 |
21 |
6 |
Tabela 5.15
Partições SGLN-96 Fonte: EPCglobal
Prefixo da Companhia(Company Prefix) – Contêm um acomodamento literal do Prefixo da Companhia da EAN.UCC.
Referência da Locação(Location Reference)–Codifica o número de Referência da Locação GLN.
Número de Série(Serial Number) - Contêm um número serial.O campo de número serial é reservado não deve ser utilizado , até que comunidade EAN.UCC determine uma forma apropriada , se houver , de estendê-lo para GLN.
5.3.7 Global Returnable Asset
Identifier (GRAI)
O esquema de codificação EPC GRAI permite o acomodamento direto do padrão GRAI da EAN.UCC em tags EPC. Em todos os casos , o dígito de checagem não é codificado. Dois esquemas são especificados : GRAI-64 (64 bits) e GRAI-96 (96 bits).
Na codificação GRAI-64 , o número limitado de bits proíbe o acomodamento direto do padrão GRAI. Como solução parcial , um Índice de Prefixo da Companhia é utilizado. Esse Índice , que pode acomodar até 16.384 códigos , é atribuído a companhias que necessitam utilizar tags de 64 bits , em adição aos seus Prefixos de Companhia EAN.UCC existentes.Esse Índice é codificado em um tag no lugar do Prefixo da Companhia , e é em seqüência traduzido para o Prefixo da Companhia em níveis mais baixos de componentes da rede EPC(Leitor ou Savant). Enquanto isso representa que apenas um número limitado de Prefixos de Companhia podem ser representados em tags de 64 bits , esse é um passo transitório para a acomodação total de esquemas de codificações de 96 bits e demais esquemas.
5.3.7.1
GRAI-64
Além do Header , o esquema de codificação GRAI-64 inclui quatro campos: o Valor de Filtragem , Índice de Prefixo da Companhia , Tipo de Ativo e Número de Série , como mostra a tabela 5.16.
|
|
Header |
Valor
de Filtragem |
Índice de Prefixo da Companhia |
Tipo
de Ativo |
Número
de
Série |
|
GRAI-64 |
8 |
3 |
14 |
20 |
19 |
|
0000 1010 (Valor Binário) |
8 (Capacidade Decimal) |
16.383 (Capacidade Decimal) |
999.999 – 9 (Capacidade Decimal*) |
524.288 (Capacidade Decimal) |
*Capacidade
do campo Tipo do Ativo varia de acordo
com o Prefixo da Companhia
Tabela 5.16 Esquema de Codificação
GRAI-64 Fonte: EPCglobal
Header – Possui 8 bits , com valor binário de 00001010.
Valor de Filtragem(Filter Value) – Não é parte da identidade pura GRAI , mas representa dados adicionais utilizados para filtragem rápida e pré-seleção de tipos básicos de ativos. O Valor de Filtragem para os esquemas GRAI de 64 e 96 bits são os mesmos. As especificações normativas para os Valores de Filtragem não estão definidas até o momento. Entretanto , essa especificação antecipa que Filtros de Valores válidos serão determinados uma vez que haja tempo para considerarem-se possíveis casos de uso.
|
Tipo |
Valor
Binário |
|
tbd |
tbd |
|
Reservado |
xxx |
Tabela 5.17
Valores de Filtragem GRAI (Não-normativos)
Fonte: EPCglobal
Índice de Prefixo da Companhia (Company Prefix Index) – Codifica o Prefixo de Companhia EAN.UCC. O valor desse campo não é o Prefixo em si , e sim um índice em um tabela que provê o Prefixo da Companhia assim como uma indicação do tamanho do Prefixo. A forma como um hardware ou software possa obter os conteúdos da tabela de tradução está especificada no documento Translation of 64-bit Tag Data Encoding Company Prefix Indices Into EAN.UCC Company Prefixes (EPCglobal).
Tipo de Ativo(Asset
Type) – Codifica a
número do Tipo de Ativo GRAI.
Número de Série(Serial Number) – Contêm um número serial.A representação EPC é capaz apenas de representar um subconjunto de Números Seriais permitidos nas especificações gerais da EAN.UCC. A capacidade desse número serial obrigatório é menor do que a máximo especificado para números seriais nas especificações da EAN.UCC.Além disso , não são permitidos zeros iniciais , e apenas números são permitidos.
5.3.7.2
GRAI-96
Além do Header , o esquema de codificação GRAI-96 possui outros cinco campos: o Valor de Filtragem , Prefixo da Companhia , Tipo de Ativo e Número de Série , como mostra a tabela 5.18.
|
|
Header |
Valor
de Filtragem |
Partição |
Prefixo
da Companhia |
Tipo
de Ativo |
Número
de
Série |
|
GRAI-96 |
8 |
3 |
3 |
20 - 40 |
24 - 4 |
38 |
|
0011 0011 (Valor Binário) |
8 (Capacidade Decimal) |
8 (Capacidade Decimal) |
999.999 – 999.999.999. 999 (Capacidade Decimal*) |
9.999.999 – 9 (Capacidade Decimal*) |
274.877.906.943 (Capacidade Decimal) |
*Capacidade dos campos Prefixo da
Companhia e Tipo de Ativo variam de
acordo com o conteúdo do campo Partição
Tabela 5.18 Esquema de Codificação
GRAI-96 Fonte:
EPCglobal
Header – Possui 8 bits , com valor binário de 00110011.
Valor de Filtragem(Filter Value) – Não faz parte dos identificadores EPC ou GRAI , mas é utilizado para filtragem rápida e pré-seleção de tipos básicos de ativos.Os Valores de Filtragem para GLN de 64 e 96 bits são os mesmos , conforme mostra a tabela 5.17.
Partição (Partition) – É a indicação de onde os números subseqüentes (Prefixo da Companhia e Tipo de Ativo) estão divididos. Essa organização coincide com a estrutura GRAI da EAN.UCC , onde o Prefixo da Companhia adicionado ao número do Tipo de Ativo totalizam 13 dígitos , já que o Prefixo da Companhia varia de 6 a 12 dígitos , e o de Tipo de Ativo de 7 a 1 dígito(s). Os valores disponíveis de Partição e os tamanhos correspondentes do Prefixo da Companhia e de Tipo de Ativo estão definidos na tabela 5.19.
|
Valor
de Partição (P) |
Prefixo
da Companhia |
Tipo
de Ativo |
||
|
|
Bits (M) |
Dígitos (L) |
Bits (N) |
Dígitos |
|
0 |
40 |
12 |
4 |
1 |
|
1 |
37 |
11 |
7 |
2 |
|
2 |
34 |
10 |
10 |
3 |
|
3 |
30 |
9 |
14 |
4 |
|
4 |
27 |
8 |
17 |
5 |
|
5 |
24 |
7 |
20 |
6 |
|
6 |
20 |
6 |
24 |
7 |
Tabela 5.19
Partições GRAI-96 Fonte: EPCglobal
Prefixo da Companhia(Company Prefix) – Contêm um acomodamento literal do Prefixo da Companhia da EAN.UCC.
Tipo de Ativo(Asset Type) – Codifica o número do Tipo de Ativo GRAI.
Número de Série(Serial Number) - Contêm um número serial. A representação EPC é capaz apenas de representar um subconjunto de Números Seriais permitidos nas especificações gerais da EAN.UCC. A capacidade desse número serial obrigatório é menor do que a máximo especificado para números seriais nas especificações da EAN.UCC.Além disso , não são permitidos zeros iniciais , e apenas números são permitidos.
5.3.8 Global Individual Asset
Identifier (GIAI)
O esquema de codificação EPC GIAI permite o acomodamento direto do padrão GIAI da EAN.UCC em tags EPC(exceto para tags de 64 bits , conforme observado abaixo).Dois esquemas são especificados : GIAI-64 (64 bits) e GIAI-96 (96 bits).
Na codificação GIAI-64 , o número limitado de bits proíbe o acomodamento literal do Prefixo da Companhia da EAN.UCC. Como solução parcial , um Índice de Prefixo da Companhia é utilizado. Esse Índice , que pode acomodar até 16.384 códigos , é atribuído a companhias que necessitam utilizar tags de 64 bits , em adição aos seus Prefixos de Companhia EAN.UCC existentes.Esse Índice é codificado em um tag no lugar do Prefixo da Companhia , e é em seqüência traduzido para o Prefixo da Companhia em níveis mais baixos de componentes da rede EPC(Leitor ou Savant). Enquanto isso representa que apenas um número limitado de Prefixos de Companhia podem ser representados em tags de 64 bits , esse é um passo transitório para a acomodação total de esquemas de codificações de 96 bits e demais esquemas.
5.3.8.1
GIAI-64
Além do Header , o esquema de codificação GIAI-64 é composto de mais três campos: o Valor de Filtragem , Índice de Prefixo da Companhia e Referência Individual do Ativo, como mostra a tabela 5.20.
|
|
Header |
Valor
de Filtragem |
Índice de Prefixo da Companhia |
Referência
Individual do Ativo |
|
GIAI-64 |
8 |
3 |
14 |
39 |
|
0000 1011 (Valor Binário) |
8 (Capacidade Decimal) |
16.383 (Capacidade Decimal) |
549.755.813.888 (Capacidade Decimal) |
Tabela
5.20 Esquema de Codificação GIAI-64 Fonte:
EPCglobal
Header – Possui 8 bits , com valor binário de 00001011.
Valor de Filtragem(Filter Value) – Não é parte da identidade pura GIAI , mas representa dados adicionais utilizados para filtragem rápida e pré-seleção de tipos básicos de ativos. O Valor de Filtragem para os esquemas GRAI de 64 e 96 bits são os mesmos. As especificações normativas para os Valores de Filtragem não estão definidas até o momento. Entretanto , essa especificação antecipa que Filtros de Valores válidos serão determinados uma vez que haja tempo para considerarem-se possíveis casos de uso.
|
Tipo |
Valor
Binário |
|
tbd |
tbd |
|
Reservado |
xxx |
Tabela 5.21
Valores de Filtragem GIAI (Não-normativos)
Fonte: EPCglobal
Índice de Prefixo da Companhia (Company Prefix Index) – Codifica o Prefixo de Companhia EAN.UCC. O valor desse campo não é o Prefixo em si , e sim um índice em um tabela que provê o Prefixo da Companhia assim como uma indicação do tamanho do Prefixo. A forma como um hardware ou software possa obter os conteúdos da tabela de tradução está especificada no documento Translation of 64-bit Tag Data Encoding Company Prefix Indices Into EAN.UCC Company Prefixes (EPCglobal).
Referência Individual do Ativo(Individual Asset Reference) – É um número único para cada instância. A representação EPC é capaz apenas de representar um subconjunto das referências de ativos permitidos nas especificações gerais da EAN.UCC.A capacidade dessa referência de ativo é menor do que o máximo especificado para referências de ativo nas especificações da EAN.UCC. Além disso , zeros iniciais não são permitidos , e apenas números são permitidos.
5.3.8.2
GIAI-96
Além do Header , o esquema de codificação GIAI-96 é composto de mais quatro campos: Valor de Filtragem , Partição , Prefixo da Companhia e Referência Individual do Ativo , como mostra a tabela 5.22.
|
|
Header |
Valor
de Filtragem |
Partição |
Prefixo
da Companhia |
Referência
Individual do Ativo |
|
GIAI-96 |
8 |
3 |
3 |
20 - 40 |
62 - 42 |
|
0011 0100 (Valor Binário) |
8 (Capacidade Decimal) |
8 (Capacidade Decimal) |
999.999 – 999.999.999. 999 (Capacidade Decimal*) |
4.611.686.018.427.387.904 – 4.398.046.511.103 (Capacidade Decimal*) |
*Capacidade dos campos Prefixo da
Companhia e Referência Individual do Ativo
variam de acordo com o conteúdo do campo Partição
Tabela 5.22 Esquema de
Codificação GIAI-96 Fonte: EPCglobal
Header – Possui 8 bits , com valor binário de 00110100.
Valor de Filtragem(Filter Value) – Não faz parte dos identificadores EPC ou GIAI , mas é utilizado para filtragem rápida e pré-seleção de tipos básicos de ativos.Os Valores de Filtragem para GLN de 64 e 96 bits são os mesmos , conforme mostra a tabela 5.21.
Partição (Partition) – É a indicação de onde os números subseqüentes (Prefixo da Companhia e Referência Individual do Ativo) estão divididos. Essa organização coincide com a estrutura GIAI da EAN.UCC , onde o Prefixo da Companhia varia de 6 a 12 dígitos. Os valores disponíveis de Partição e os tamanhos correspondentes do Prefixo da Companhia e de Referência do Ativo estão definidos na tabela 5.23.
|
Valor
de Partição (P) |
Prefixo
da Companhia |
Referência
Individual do Ativo |
||
|
|
Bits (M) |
Dígitos (L) |
Bits (N) |
Dígitos |
|
0 |
40 |
12 |
42 |
12 |
|
1 |
37 |
11 |
45 |
13 |
|
2 |
34 |
10 |
48 |
14 |
|
3 |
30 |
9 |
52 |
15 |
|
4 |
27 |
8 |
55 |
16 |
|
5 |
24 |
7 |
58 |
17 |
|
6 |
20 |
6 |
62 |
18 |
Tabela 5.19
Partições GIAI-96 Fonte: EPCglobal
Prefixo da Companhia(Company Prefix) – Contêm um acomodamento literal do Prefixo da Companhia da EAN.UCC.
Referência Individual do Ativo(Individual Asset Reference) – É um número único para cada instância. A representação EPC é capaz apenas de representar um subconjunto de referências de ativo permitidos nas especificações gerais da EAN.UCC. A capacidade dessa referência do ativo é menor do que a máximo especificado para referências de ativo nas especificações da EAN.UCC.Além disso , não são permitidos zeros iniciais , e apenas números são permitidos.
5.4
Representação URI
Esse sub-capítulo mostra a codificação de um EPC como um URI (Uniform Resource Identifier).A Codificação URI complementa as codificações EPC , sendo definida para ser utilizada em tags RFID e outros componentes situados em níveis mais baixos da arquitetura de redes de auto-identificação. Os URIs fornecem meios para as aplicações de software manipularem EPCs de uma forma que seja independente de qualquer outra representação à nível de tag , desta forma abstraindo da lógica da aplicação a maneira como um EPC foi obtido de um tag.
A seguir , serão definidas duas categorias de URIs. A primeira são os URIs para identidades puras , às vezes chamada também de forma canônica. Essa categoria contém apenas as únicas informações que identificam um objeto físico específico , e são independentes de codificações de tag. A segunda categoria são os URIs que representam codificações específicas de tags. Esses URIs são utilizados em aplicações de software onde o esquema de codificação é relevante , assim como quando comandos de software são utilizados para escrever dados em um tag , por exemplo.
Todas as categorias de URI são representadas como URNs (Uniform Resource Names) , assim como definidos pela especificação RFC2141 , onde o Namespace URN é: epc.
Desta forma , esse sub-capítulo complementa o sub-capítulo anterior (5.3) , que por sua vez especifica a definição corrente da representação do EPC em nível de tag.
5.4.1 Formas URI para Identidades
Puras
Formas URI são providas para identidades puras , que contém apenas os campos EPC que servem para distinguir um objeto de outro.Esses URIs tomam a forma de URNs (Uniform Resource Names) , com um namespace URN alocado distintamente para cada identidade pura.
Para o padrão EPC GID (General Identifier) , a representação URI de identidade pura é a seguinte:
urn : epc : id: gid : General ManagerNumber . ObjectClass . SerialNumber
Nessa representação , os três campos General Manager Number (Número Geral Diretor) , Object Class (Classe de Objeto) e Serial Number (Número de Série) correspondem aos três componentes do esquema de codificação EPC GID (descrito no sub-capítulo 5.3.3).Na representação URI , cada campo é expresso como um número decimal inteiro e sem zeros iniciais (exceto quando o valor de um campo é igual a zero , sendo neste caso um único zero utilizado como dígito).
Há também formas URI de identidades puras definidas para tipos de identidade correspondentes à certos tipos dentro da família de esquemas da EAN.UCC (definidas no sub-capítulo 5.2.2) , nomeadas como : Serialized Global Trade Identifier(SGTIN) ; Serial Shipping Container Code(SSCC) ; Serialized Global Location Number(SGLN) ; Global Reusable Asset Identifier(GRAI) e Global Individual Asset Identifier(GIAI).As representações URI correspondentes a esses identificadores são descritas abaixo.Note que apenas os campos que identificam o esquema são contemplados , já que esta representação age na camada de identidade pura EPC .Ou seja , campos que são utilizados para identificar o esquema em função do total de bits , por exemplo (Header, Partição,etc), não são contemplados. Por isso , as representações URI descritas abaixo não são divididas como as da camada de codificação (GTIN-64/GTIN-96 , SSCC-64/SSCC-96, SGLN-64/SGLN-96 , GRAI-64/GRAI-96 , GIAI-64/GIAI-96) , e sim definidas de acordo com a camada de identidade pura.
urn : epc : id: sgtin : CompanyPrefix . ItemReference . SerialNumber
urn : epc : id: sscc : CompanyPrefix . SerialReference
urn : epc : id: sgln : CompanyPrefix . LocationReference . SerialNumber
urn : epc : id: grai : CompanyPrefix . Asse Type . SerialNumber
urn : epc : id: giai : CompanyPrefix . IndividualAssetReference
Nessas representações , Company Prefix (Prefixo da Companhia) correspondem ao prefixo da companhia EAN.UCC atribuído a um fabricante pela EAN ou pela UCC (um prefixo de companhia UCC é convertido em um prefixo de companhia EAN.UCC através da adição de um zero inicial no início). O número de dígitos nesse campo é significativo , e zeros iniciais são incluídos quando necessário.
Os campos Referência do Item (Item Reference) , Referência Serial (Serial Reference) , Referência da Locação (Location Reference) e Tipo de Ativo (Asset Type)são correspondentes aos campos similares dos esquemas GTIN , SSCC , GLN e GRAI , respectivamente. Assim como no campo Prefixo da Companhia (Company Prefix) , o número de dígitos nesses campos são significativos , e zeros iniciais são incluídos quando necessário. O número de dígitos nesses campos , quando adicionados ao número de dígitos
do campo Prefixo da Companhia (Prefix Company) , sempre totalizam o mesmo número de dígitos de acordo com o tipo de identidade : 13 dígitos para SGTIN , 17 dígitos para SSCC, 12 dígitos para SGLN e 12 dígitos para GRAI. O campo Referência do Item (Item Reference) do esquema SGTIN incluem o dígito Indicador GTIN (PI) , adicionado ao começo da referência do item. O campo Referência Serial (Serial Reference) inclui o Dígito de Extensão SSCC (ED) adicionado ao começo da referência serial. Em nenhum dos casos são incluídos dígitos de checagem na Representação URI).
Em contraste aos outros campos , os campos Número de Série (Serial Number) dos esquemas SGTIN , SGLN e GRAI ,assim como o campo Referência Individual do Ativo (Individual Asset Reference) do esquema GIAI , são números inteiros , sem zeros iniciais.
Os esquemas SGTIN , SSCC , assim como os demais citados ; são conhecidos nesta forma como forma SGTIN-URI , forma SSCC-URI , e assim por diante , respectivamente. Abaixo seguem alguns exemplos:
urn : epc : id: sgtin : 0652642 . 800031 . 400
urn
: epc : id: sscc : 0652642 . 0123456789
urn : epc : id: sgln : 0652642 . 12345 . 400
urn : epc : id: grai : 0652642 . 12345 . 1234
urn : epc : id: giai : 0652642 . 123456
Em relação ao primeiro exemplo , o código correspondente GTIN-14 é 80652642000311. Esse código divide-se em : o primeiro dígito (8) é o dígito PI , que aparece como o primeiro dígito do campo Referência do Item no URI , os próximos sete dígitos (0652642) são os do Prefixo da Companhia , os próximos cinco dígitos (00031) são os remanescentes da Referência do Item , e o último dígito (1) é o dígito de checagem , que não é incluído no URI.
Em relação ao segundo exemplo , o SSCC correspondente é o 006526421234567896 e o último dígito (6) é o dígito de checagem , não incluído no URI.
Em relação ao terceiro exemplo , o
GLN correspondente é o 0652642123458 onde o último dígito (8) é o dígito de
checagem , não incluído no URI.
Em relação ao quarto exemplo , o GRAI correspondente é o 006526421234581234 onde o dígito (8) é o dígito de checagem , não incluído no URI.
Em relação ao quinto exemplo , o GIAI correspondente é o 0652642123456(a codificação GIAI não inclui um dígito de checagem).
Todas as cinco formas URI possuem uma indicação explícita da divisão entre o prefixo da companhia e o restante do código. Isso é necessário para que a representação URI possa ser convertida em codificações de tags. Em geral , a representação URI pode ser convertida na forma numérica EAN.UCC correspondente (através da combinação dos dígitos e do cálculo do dígito de checagem), mas por outro lado a conversão da forma numérica EAN.UCC para a representação URI correspondente requer conhecimentos independentes do tamanho do prefixo da companhia.
5.4.2 Formas URI para Tags EPC
Há diversos tipos de dados que comumente ocorrem em aplicações que manipulam Códigos Eletrônicos de Produto (EPC) , mas que não são EPC em si , e sim relacionados proximamente a eles. A especificação URI provê formas URI para todos esses tipos de dados. A forma geral do Namespace URN epc é o seguinte:
urn
: epc : tipo . ParteEspecíficadoTipo
O campo tipo identifica um tipo de dado particular , e o campo ParteEspecíficadoTipo codifica as informações apropriadas para aquele tipo de dado. Neste sub-capítulo será descrito o tipo específico definido como tag
Esse tipo foi definido porque , em alguns casos ,é desejável codificar na forma URI uma codificação de tag EPC específica.Por exemplo , uma aplicação pode desejar reportar a um operador que tipos de tag foram lidos.Em outro exemplo , uma aplicação responsável pela programação de tags precisa ser avisada não apenas que EPC deve ser colocado em um tag , mas também codificar o esquema a ser utilizado.Finalmente , aplicações que queiram manipular qualquer campo de dados adicional em tags precisam de alguma outra representação que não a de identidade pura.
URIs de tags EPC são codificadas através do preenchimento do campo tipo , sendo que o URI tenha esse formato:
urn : epc : tag : EncName . EncodingSpecificFields (onde EncName é o nome do esquema de codificação EPC , e EncodingSpecificFields denotam os campos de dados requeridos pelo esquema de codificação , separados por pontos.Os campos exatos presentes dependem do esquema de codificação utilizado).
Em geral , há um ou mais esquemas de codificação (e os valores de EncName correspondentes) definidos para cada identidade pura.Por exemplo , o Identificador SGTIN possui duas codificações definidas: sgtin-96 e sgtin-64 , que correspondem , respectivamente , aos esquemas de 96 bits e 64 bits.Note que esses esquemas de codificação estão em correspondência um-a-um com únicos valores de Header , que são utilizados para representar o esquema de codificação de tag em si.
Os campos denotados como EncodingSpecificFields , em geral , incluem todos os campos correspondentes para cada tipo de identidade pura , possivelmente com restrições adicionais na faixa numérica , além de campos adicionais suportados pela codificação . Por exemplo , todas as codificações definidas para SGTIN incluem um Valor de Filtragem adicional , que as aplicações utilizam para realizar filtragem de tags baseada em características do objeto associadas à sua identidade pura.
Abaixo há um exemplo de uma codificação para SGTIN-64:
urn : epc : tag : sgtin-64 : 3 . 0652642 . 800031 . 400
Nesse exemplo , o número 3 é o Valor de Filtragem.
|
Capítulo 6 |
Savant |
6.1
Arquitetura de Sistema das Redes EPC
A partir desse capítulo , serão descritos os componentes que formam uma Rede EPC , de acordo com as definições da organização EPCglobal ; e em especial da estrutura destinada à manipulação dos dados através de um Sistema de Informação. Para ilustrar melhor a estrutura de uma Rede EPC , abaixo segue a figura da arquitetura de uma rede dessa espécie dentro de uma empresa. Note que alguns desses componentes já foram detalhados dentro deste trabalho , pois tratam-se de componentes RFID (tags e leitores).
Figura 6.1 Arquitetura da Rede EPC: Componentes e Camadas Fonte: EPCglobal
Abaixo segue uma descrição funcional e o papel de cada um dos componentes mostrados na figura 6.1 e que formam a Rede EPC:
Leitores – Conforme já citado anteriormente , os leitores são dispositivos
responsáveis por detectar quando os tags adentram
em seu campo de leitura. Eles podem também ser capazes de interagir com outros
sensores acoplados ou embutidos em tags.
A especificação nomeada como Auto-ID
Reader Protocol Specification 1.0 define um protocolo padrão pelo qual os
Leitores se comunicam com Savants e outros hosts.
O Savant possui também um “adaptador” que funciona como uma interface para
leitores antigos que não possuem implementado em si o Auto-ID Reader Protocol.
Savant – É um software que funciona como um “middleware” , desenvolvido para processar os pacotes de dados de tags ou sensores(dados de eventos) que chegam a um ou mais dispositivos de leitura.O Savant realiza o filtro , a agregação e a contagem de dados de tags , reduzindo assim o volume de dados a serem enviados para as aplicações comerciais de software existentes em uma determinada empresa.A especificação Auto-Id Savant Specification 1.0 (que será melhor detalhada durante este capítulo)define o modo de trabalho do Savant , além de sua interface com as aplicações de software de uma empresa.
EPC Information Service – O EPC Information Service faz com que a Rede EPC esteja relacionada com dados disponíveis em formato PML , para que , a partir daí , faça a requisição de serviços. O dados disponibilizados através do EPC Information Service podem incluir : dados lidos de tags coletados através dos Savants (por exemplo para auxiliar no rastreamento de números seriais) ; dados de instâncias , como data de fabricação , data de validade , e assim por diante ; e dados relacionados a classes de objetos , como catálogos de informação de produtos.Para responder às requisições , o EPC Information Service extrai , por sua vez ,uma variedade de dados que existam através da empresa , e em seguida os traduz para o formato PML. Quando os dados EPC são distribuídos através do supply chain , uma indústria pode criar um Registro de Acesso EPC (EPC Access Registry) que irá atuar como um repositório para as descrições de interface do EPC Information Service .O especificação Auto-ID EPC Information Service Specification 1.0 define o protocolo para o acesso ao EPC Information Service.
ONS(Object Name Service) – O Object Name Service (ONS, que será descrito no capítulo 8) provê um serviço de procura global para a tradução de um EPC em uma ou mais URLs (Internet Uniform Reference Locators) , onde informações adicionais do objeto possam ser encontradas.Essas URLs geralmente identificam um EPC Information Service , embora o ONS possa ser utilizado também para associar EPCs à web sites e outros recursos da Internet relevantes a um objeto.O ONS provê serviços tanto dinâmico quanto estático. O ONS Estático tipicamente provê URLs para informações mantidas por um fabricante de um determinado artigo. Já o ONS Dinâmico registra a seqüência de custódias pelo qual um objeto possa passar através do suplly chain , podendo desta forma informar todos os pontos que ele passou desde o momento de sua fabricação. O ONS é construído com base na mesma tecnologia que o DNS (Domain Name Service) da Internet. A especificação Auto-ID Object Name Service Specification 1.0 define o funcionamento do ONS e sua interface à aplicações.
ONS Local Cache – O ONS Local Cache é utilizado para reduzir a necessidade de consultas ao ONS Global de cada objeto visível à rede , já que valores recém-solicitados podem ser armazenados em um cache local , que funciona como um primeiro ponto de chamadas para as consultas ao ONS. O cache local pode também gerenciar a procura de EPCs internos privados para rastreamento de ativos. Associado ao cache local estarão as funções de registro que registram EPCs junto ao ONS Global e com o sistema ONS dinâmico , a fim de prover rastreamento privado e outros recursos de colaboração ao suplly chain percebido por cada objeto único.
Padrões de Dados das Redes EPC – Neste caso dois padrões fundamentais são definidos:
- Electronic Product Code (EPC) – Conforme descrito anteriormente , o EPC é o
identificador fundamental de um objeto físico.A especificação Auto-ID Electronic Product Code Data Specification 1.0 (detalhada no capítulo 5) define o conteúdo abstrato do Código Eletrônico do Produto(EPC) , além de sua realização concreta na forma de tags RFID , URIs de Internet , e outras representações.
- Physical Markup Language (PML) - A PML é uma coleção de vocabulários XML comuns e padronizados , que representa e distribui informações relacionadas aos objetos ativos dentro da Rede EPC. A PML padroniza o conteúdo das mensagens exportadas dentro da Rede. Por isso , ela é parte do esforço da EPCglobal em desenvolver interfaces e protocolos padronizados para a comunicação dentro da infra-estrutura definida pela organização. O core(ou seja , a base(ou “núcleo”) de definições da linguagem) , da Physical Markup Language conhecido como PML Core , provê um formato padrão para a exportação de dados capturados pelos sensores da infra-estrutura EPC , como por exemplo os leitores RFID.A especificação Auto-ID PML Core Specification 1.0 (que será melhor detalhada no capítulo 7) define as sintaxes e semânticas do PML Core.
6.2
Savant – Visão Geral
O Savant é um sistema (software) que situa-se entre os leitores de tags e as aplicações de software comerciais das empresas que o utilizam. Ele é destinado à direcionar os requisitos computacionais exclusivos das redes EPC. Muitos dos desafios das aplicações de software neste ambiente são resultado do vasto volume de dados detalhados originados pelos leitores RF , que são muito grandes quando comparados com a granularidade dos dados que tradicionalmente as empresas estão acostumadas a manipular. Por isso , boa parte do processamento realizado pelo Savant está concentrado na redução de operações como a filtragem , agregação e contagem. Ao mesmo tempo , outros desafios nas aplicações surgem de outros elementos da rede EPC , incluindo os componentes ONS e PML.
Requisitos específicos para processamento EPC variam muito de aplicação para aplicação. Além disso , o EPC ainda está em trajetória inicial , e até que as idéias pertinentes a ele amadureçam , haverá grandes inovações e até mesmo mudanças no comportamento das aplicações. Por isso , a ênfase na especificação do Savant é muito maior do que nas características de processamentos específicos , ou seja , é maior no aspecto conceitual do sistema. O Savant é definido em termos de Módulos de Processamento(Processing Modules) ou Serviços(Services) , sendo que cada um provê um conjunto de funcionalidades que podem ser combinadas pelo usuário para irem de encontro à uma ou outra aplicação.A estrutura modular é desenvolvida para promover inovações feitas por grupos independentes de pessoas , evitando assim a criação de uma especificação única e monolítica que tente satisfazer a todos.
Figura 6.2 Savant: Módulos e Interfaces Fonte: EPCglobal
O Savant em si pode ser considerado um recipiente de módulos de processamento. Os Módulos de Processamento interagem com o mundo externo através de duas interfaces definidas na especificação do Savant. A Interface do Leitor provê a conexão com os leitores de tags , principalmente com leitores RFID. Os detalhes desta interface estão definidos em uma outra especificação , chamada de Auto-ID Reader Protocol 1.0 Specification (ou simplesmente Reader Protocol 1.0) ; entretanto o Savant também permita conexões a leitores através de outros protocolos.
A Interface de Aplicações provê a conexão à aplicações externas , que em geral são aplicações comerciais de software existentes em uma determinada empresa , mas que também podem ser novas aplicações específicas para EPC e até mesmo outros Savants.A Interface de Aplicações é definida por um protocolo que será melhor detalhado durante todo este capítulo. Essa Interface é especificada em termos de conjuntos de comandos , onde cada conjunto é definido através de um Módulo de Processamento. Assim , essa Interface serve como um canal comum entre os módulos de processamento do Savant e as aplicações externas.Se necessário , os Módulos de Processamento devem se comunicar com serviços externos pré-existentes usando os protocolos nativos desses serviços.A Interface de Aplicação é especificada através da utilização de uma modelo de camadas similar ao empregado no protocolo Reader Protocol 1.0 , onde uma camada define os comandos e suas sintaxes abstratas , enquanto uma camada mais inferior especifica a definição de um protocolo e sintaxe específicos, sendo que diversas definições podem ser feitas.
Além das duas interfaces externas definidas
para o Savant (Interface do Leitor e Interface de Aplicação) , Módulos de
Processamento podem interagir uns com os outros através de APIs que são
definidas através deles mesmos.Módulos de Processamento podem também interagir
com outros serviços externos através de interfaces disponibilizadas por esses
serviços.Um caso especial de interação é quando um Savant se comunica com
outro. Entretanto , a especificação descrita neste capítulo não define como os
Módulos de Processamento ganham acesso à tais serviços externos. Mais uma vez ,
como as especificações são ainda muito recentes , é esperado que uma futura
especificação defina como os módulos de processamento acessem serviços externos
particulares , especialmente os EPCs Information Services , ONS , além de
outras instâncias de Savant.
Módulos de Processamento são definidos ou por normas da EPCglobal ou por usuários e partes terceiras. Esses Módulos de Processamento definidos pelas normas da EPCglobal são chamados Módulos de Processamento Padrões.Cada implementação de Savant deve prover uma implementação para cada Módulo de Processamento Padrão. Alguns Módulos Padrões são requeridos a estar presentes em qualquer instância de desenvolvimento envolvendo o Savant ; esses são chamados de Módulos de Processamento Padrões REQUERIDOS (a letra maiúscula utilizada nesta e em outras definições está baseada na norma IETF RFC 2119 , para que seja possível denotar de forma distinta o que faz parte dos padrões da EPCglobal). Outros podem ser incluídos ou omitidos pelo usuário em uma determinada instância ; esses são chamados de Módulos de Processamento Padrões OPCIONAIS.
Na especificação Savant Specification 1.0 , há apenas dois Módulos de Processamento Padrões definidos. O primeiro é um Módulo REQUERIDO chamado autoid.core. Esse Módulo provê um conjunto mínimo de comandos de Interface de Aplicação que permitem que aplicações saibam o que outros Módulos de Processamento disponibilizam , e que capturam informações básicas sobre quais leitores estão conectados. O segundo Módulo também é um REQUERIDO , e chama-se autoid.readerproxy.Esse Módulo Padrão fornece meios à aplicações a disparar comandos diretamente aos leitores através da Interface de Aplicações.
Na seqüência do Capítulo 6 , as especificações dos componentes do Savant (Interface do Leitor , Módulos de Processamento Padrões , Interface de Aplicação , Modos de Transporte de Mensagens da Interface de Aplicação) serão melhores detalhadas.
6.3
Interface do Leitor
Esse sub-capítulo descreve a interação entre o Savant e os dispositivos de leitura , principalmente os leitores de tags RFID. Todos os dispositivos serão referenciados genericamente como “Leitores” no restante desse sub-capítulo.
Essa descrição será mostrada através das normas já definidas pela EPCglobal , ou seja , em forma de definições que devem ser consideradas requisitos oficiais para a implementação do Savant em uma rede EPC.
A seguir seguem essas normas, que são divididas em quatro tópicos principais:
1) Suporte ao protocolo Auto-ID Reader Protcol 1.0:
- Uma implementação de Savant DEVE suportar a interação entre leitores utilizando o Auto-ID Reader Protocol 1.0 [ReaderProtocol1.0].
- Uma implementação de Savant DEVE suportar ao menos um dos modos de Mensagem / Transporte especificados no Auto-ID Reader Protocol 1.0 [ReaderProtocol1.0].
- Uma implementação de Savant DEVERIA suportar tanto modos de Mensagem / Transporte especificados no [ReaderProtocol1.0] quantos forem utilizados na prática.
- Uma implementação de Savant DEVE prover aos Módulos de Processamento um meio de acesso a todos os comandos especificados no [ReaderProtocol1.0] , incluindo comandos definidos no [ReaderProtocol1.0] como RECOMENDADOS ou OPCIONAIS.
2) Suporte a outros
protocolos de Leitores:
-
Uma implementação de Savant PODE suportar a interação entre Leitores
utilizando outros protocolos que não o [ReaderProtocol1.0].
3) Suporte à extensões
de protocolos de Leitores de fabricantes específicos:
-
Uma implementação de Savant DEVE prover aos seus módulos um meio de
invocar extensões do [ReaderProtocol1.0] de fabricantes específicos.
4) Número de Leitores:
-
Uma implementação de Savant DEVE permitir a interação com pelo menos
um leitor.
-
Implementações de Savant PODEM limitar o número de Leitores ,
sendo que a interação simultânea entre eles é permitida. Implementações PODERIAM evitar a colocação arbitrária
do limite do número de leitores , a ao invés disso permitir que o número de
leitores seja limitado apenas pela quantidade de memória disponível no Savant
ou pelo limite de conexões de I/O dos Sistemas Operacionais envolvidos.
6.4
Módulos de Processamento
Esse sub-capítulo especifica como os Módulos de Processamento e utilizados no Savant.
Essa descrição será mostrada através das normas já definidas pela EPCglobal , ou seja , em forma de definições que devem ser consideradas requisitos oficiais para a implementação do Savant em uma rede EPC.
A seguir seguem essas normas, que são divididas em sete tópicos principais:
1) Definição:
- Uma implementação de Savant contém um ou mais Módulos de Processamento. Uma implementação de Savant PODE prover um meio para a criação de Módulos de Processamento para aplicações específicas.
2) Acesso à Interfaces
Externas Padrões:
- Uma implementação de Savant DEVE prover um meio para a interação entre Módulos de Processamento e Leitores.
- Uma implementação de Savant DEVE prover um meio aos Módulos de Processamento para que estes possam receber e responder a comandos através do Canal de Controle da Interface de Aplicações.
- Uma implementação de Savant DEVE prover um meio aos Módulos de Processamento para o envio de notificações assíncronas através do Canal de Notificação da Interface de Aplicações.
3) Interação entre Módulos
de Processamento:
- Uma implementação de Savant PODE permitir que Módulos de Processamento exponham APIs que sejam acessíveis a outros Módulos de Processamento na mesma instância de funcionamento do Savant. Essas APIs PODEM incluir operações que não estejam disponíveis através da Interface de Aplicações.
4) Interação com outros
Serviços Externos:
- Uma implementação de Savant PODE permitir que os Módulos de processamento estabeleçam conexões e interajam com outros serviços externos , através de outras interfaces além das Interfaces do Leitor e de Aplicações.
- Uma implementação de Savant PODERIA prover acesso ao ONS e ao EPC Information Service.
- Uma implementação de Savant PODE permitir que Módulos de Processamento estabeleçam conexões com outras instâncias de Savant.Neste caso , esses Módulos seriam clients da Interface de Aplicações dessas outras instâncias.
5) Registro de Capacidades:
- Módulos de Processamento DEVEM registrar suas capacidades com o Módulo de Processamento autoid.core no momento de sua inicialização. Para a Versão 1 da Especificação do Savant será requerido o registro de seus nomes apenas com Módulo de Processamento autoid.core.
6) Suporte a Módulos de
Processamento Padrões:
- Uma implementação de Savant DEVE incluir sempre todos os Módulos de Processamento Padrões definidos como REQUERIDOS (atualmente apenas autoid.core e autoid.readerproxy).
7) Convenções para Nomes de
Módulos de Processamento:
- Cada Módulo de Processamento em uma dada instância de Savant DEVE possuir um nome único.
- Nomes de Módulos de Processamento DEVEM possuir o formato componente.componente.componente... , onde ‘.’ é o caractere Unicode de “ponto final” (002E) e cada componente é uma string não-nula de caracteres Unicode , excluindo-se o ‘.’ . Quando forem determinados dois Módulos de Processamento como nomes iguais , o Savant DEVE tratá-los de forma case- sensitive.
- Nomes de Módulos de Processamento onde o componente mais à esquerda forem autoid ou autoidx são reservados para Módulos de Processamento Padrões (Módulos de Processamento Padrões REQUIRIDOS e Módulos de processamento Padrões OPCIONAIS, respectivamente).Módulos de Processamento definidos por usuários ou partes terceiras NÃO DEVEM possuir nomes que comecem com autoid ou autoidx.
- Módulos de Processamento definidos por usuários e partes terceiras DEVERIAM possuir nomes de acordo com a convenção a seguir , que é projetada para que Módulos de Processamento definidos independentemente por diferentes organizações tenham sempre nomes distintos mesmo sem coordenação prévia. Sendo a . b...y . z um nome de domínio da Internet de propriedade de uma organização que desenvolveu um Módulo de Processamento. Então , a organização DEVERIA atribuir um nome ao Módulo de Processamento na forma z . y...b . a . XXX , onde XXX denota um ou mais componentes escolhidos pela organização que não conflitem com o nome de qualquer outro Módulo de Processamento definido pela mesma organização.
Exemplo: Se a Companhia fictícia Sample Software possui o nome de Domínio sample.com ; e quer definir um módulo de processamento para uma aplicação de inventário , ela poderia escolher um nome como com.sample.inventory.
Nota: Essa convenção foi modelada após ser definida a convenção de nomes da Java Language Specification (tJLS2) para nomear pacotes Java. Entretanto , nomes de Módulos de Processamento não tem relacionamento com nomes de pacotes Java , e certamente em nenhuma implementação de Savant é requerida para a utilização de Java em qualquer circunstância.
6.5
Interface de Aplicações
6.5.1 Estruturação em Camadas
A Interface de Aplicações é especificada em três camadas distintas , conforme mostra a figura 6.3.
Figura 6.3 Camadas da Interface de
Aplicações Fonte: EPCglobal
As camadas são as seguintes:
Camada de Conteúdo: Essa camada especifica o conteúdo abstrato das mensagens trocadas entre o Savant e as aplicações. Essa camada é o “coração” da Interface de Aplicações , definindo as operações que estão disponíveis às aplicações e o quais são seus significados.
Camada de Mensagens: Essa camada especifica como as mensagens abstratas definidas na Camada de Conteúdo são codificadas(serializadas), enquadradas, transformadas e carregadas em um transporte de rede específico. Serviços de segurança, se houverem, estão situados nesta camada. (Exemplos de serviço de segurança incluem autenticação, autorização, confidencialidade de mensagens e integridade de mensagens). A Camada de Mensagens especifica como uma conexão de rede subjacente é estabelecida ; além de qualquer inicialização requerida para o estabelecimento de sincronismo ou inicialização de serviços de segurança ; e também por qualquer processamento como por exemplo a encriptação que é realizada para cada mensagem.
Camada de Transporte: Essa camada corresponde às facilidades de rede providas pelo Sistema Operacional ou equivalente , e será especificada no sub-capítulo 6.7.
Uma instância de Savant PODE prover múltiplas alternativas de implementação na Camada de Transporte. Cada uma dessas implementações é chamada de Messaging / Transport Binding(MTB). Diferentes MTBs são providas para diferentes tipos de transportes, como por exemplo TCP/IP, Bluetooth ou linhas seriais ; e para diferentes tipos de protocolos de mensagens, como por exemplo SOAP, XML puro ou MQSeries. Diferentes MTBs podem também prover diferentes tipos de serviços de segurança.
Várias MTBs padrões são definidas neste capítulo.Outras podem ser definidas e especificadas em separadas e futuras especificações. O sub-capítulo especificará as MTBs padrões que são definidas atualmente.
Independentemente de qual MTB é utilizada , uma implementação de Savant DEVE permitir múltiplas, simultâneas e independentes conexões através da Interface de Aplicações. Os módulos de processamento DEVEM assumir que há conexões concorrentes ativas, e implementar qualquer travamento ou outra operação que garanta a operação correta frente à essa concorrência.
6.5.2 Canais de Mensagens
A interface entre a Camada de Conteúdo e a Camada de Mensagens é definida em termos de canais de mensagens, sendo que cada um representa uma comunicação independente entre uma instância do Savant e uma aplicação comercial de software de uma empresa. Pelo fato de uma dada instância de Savant poder permitir múltiplas, simultâneas e independentes conexões à essas aplicações de software através da Interface de Aplicações, em geral podem haver muitos canais de mensagens ativos de uma vez.
Canais de mensagens podem ser de dois tipos:
Canal de Controle: Um canal de controle carrega requisições de alguma aplicação de software para o Savant , e reponde à essas requisições do Savant para a aplicação. Todas as mensagens trocadas em um canal de controle seguem esse modelo de requisição / resposta.
Canal de Notificação: Um canal de notificação carrega mensagens emitidas de forma assíncrona pelo Savant para uma aplicação de software. Mensagens em um canal de notificação fluem apenas nessa direção. O canal de notificação é primeiramente utilizado para suportar um modo de operação no qual o Savant distribui de forma assíncrona informações derivadas de leituras assíncronas de tags ou outros eventos, sem que a aplicação client conectada ao Savant precise requisitar esses eventos.
Quando diversos canais estão ativos, não há nenhum exigência estipulada de que todos os canais ativos utilizem a mesma MTB. Por exemplo, uma instância de Savant ativa pode ter um Canal de Controle ativo que utilize uma MTB na forma de XML sobre HTTP , um Canal de Notificação que utilize MTB baseada em MQSeries , e outro Canal ativo de Notificação que utilize uma MTB no modo XML sobre HTTP similar à MTB do Canal de Controle, porém inicializado em sentido inverso. Essa flexibilidade é requerida porque: (a) O tráfego dos canais de controle e de notificação possuem diferentes padrões, e por isso possuem afinidades naturais com diferentes protocolos subjacentes; e (b) Diferentes aplicações específicas de software de diferentes empresas podem impor diferentes requerimentos em quais protocolos que devam ser utilizados.
Em alguns casos, um Módulo de
Processamento pode querer enviar notificações para a mesma instância da
aplicação de software client que o
está emitindo comandos. Algumas MTBs podem prover tanto um Canal de Controle
quanto um Canal de Notificação conjunto, que a multiplexa através da mesma
conexão de Camada de Transporte subjacente.
6.5.3 Estrutura dos Comandos
Canais de Controle ativos carregam tráfego de requisições/retornos entre o Savant e as aplicações comerciais de software de uma determinada empresa. Esse tráfego é processado da seguinte forma:
- Uma aplicação envia uma mensagem de requisição ao Savant em um Canal de Controle previamente estabelecido. A mensagem de requisição inclui o nome de um Módulo de Processamento, um nome de comando conhecido àquele Módulo, e qualquer argumento pertinente àquele comando ;
- O Savant dispara o comando recebido (bem como seus argumentos) ao Módulo de Processamento também mencionado ;
- O Módulo de Processamento realiza alguma função de acordo com o nome do comando recebido e seus argumentos, eventualmente retornando um resultado (que pode ser um resultado normal ou um de erro) ;
- O Savant envia o resultado de volta à aplicação, através de uma mensagem de resposta que é transportada no mesmo Canal de Controle que recebeu a requisição original.
Se no primeiro passo a mensagem de requisição especifica um Módulo Processamento que não está presente na instância ativa do Savant, este DEVE responder com uma mensagem de noSuchModule (que será definida no sub-capítulo 6.5.5). Se, no terceiro passo o Módulo de Processamento não reconhecer o nome do comando, o Savant DEVE responder com uma mensagem de noSuchCommand (também será definido no sub-capítulo 6.5.5). Outras condições de erro, como argumentos de comando inválidos, DEVEM ser manipuladas pelo Módulo de Processamento individualmente, que DEVERIA responder com uma mensagem de erro apropriada.
6.5.4 Mensagens de Requisição em Canais
de Controle
Esse sub-capítulo define o formato geral de uma mensagem de requisição de um Canal de Controle. Uma mensagem de requisição de um Canal de Controle consiste de um nome de Módulo de Processamento, um nome de comando conhecido àquele módulo, e um ou mais argumentos para aquele comando.Nas especificações dos Módulos de Processamento, cada comando é documentado através da especificação de uma lista ordenada de argumentos, com seus respectivos tipos de dados. Isso constitui uma sintaxe abstrata para o comando. Uma dada MTB define, então, como essa informação (nome do Módulo de Processamento, nome do comando e argumentos) é codificada em uma mensagem concreta. Cada MTB DEVE definir especificamente como um conjunto de comandos é estruturado e codificado.
6.5.5 Mensagens de Resposta em Canais de
Controle
Na especificação atual do Savant (versão 1.0) , estão definidos alguns tipos padrões de mensagens de respostas de Canais de Controle, conforme mostrado abaixo:
Mensagem de Resposta noSuchModule: Essa mensagem de resposta é gerada como retorno de uma mensagem de requisição que refere-se a um nome de Módulo de Processamento que não está presente em uma instância de Savant em produção.
Mensagem de Resposta noSuchCommand: Essa mensagem de resposta é gerada como retorno de uma mensagem de requisição que refere-se a um comando não reconhecido pelo Módulo de Processamento especificado.
Mensagem de Resposta de Erro: Essa mensagem de resposta é gerada pelos Módulos de Processamento em situações de erro. Todos os Módulos de Processamento Padrões retornam erros em um formato que contém um código de erro e uma mensagem de erro.
Códigos de erro variando entre 1 e 10000 são reservados aos Módulos de Processamento Padrões. Módulos de Processamento produzidos por fabricantes específicos NÃO DEVEM utilizar códigos de erro pertencentes à essa faixa. A versão atual das especificações do Savant não incluem um conjunto delimitado de códigos e mensagens de erro padrões, porém é esperado que as versões futuras o incluam.
6.6
Módulos de Processamento Padrões
Nesse sub-capítulo serão definidos os Módulos de Processamento Padrões do Savant. Módulos de Processamento Padrões possuem comportamentos e interfaces que são especificados por completo nesse sub-capítulo, e estão sempre disponíveis em qualquer implementação de Savant. Módulos de Processamento Padrões designados como REQUERIDOS devem estar sempre presentes em qualquer instância ativa de Savant. Módulos de Processamento Padrões designados como OPCIONAIS podem ser excluídos de uma instância em particular como opção do usuário. Quando um Módulo de Processamento Padrão OPCIONAL é incluído, ele deve estar de acordo com todas as especificações normativas que definem aquele Módulo Padrão. A Referência de Implementação do Savant (prevista para o futuro próximo) irá incluir uma implementação de todos os Módulos de Processamento Padrões , sendo eles REQURIDOS ou OPCIONAIS.
Nota: Na versão atual da especificação do Savant (1.0) há apenas dois Módulos de Processamento definidos , sendo que ambos são designados como REQUERIDOS (autoid.core e autoid.readerproxy).É esperado que futuras versões da Especificação do Savant irá possuir muito mais Módulos de Processamento. Exemplos de Módulos de Processamento Padrões esperados para serem definidos em um futuro próximo incluem: um módulo para prover acesso ao ONS, um Módulo para prover acesso ao EPC Information Service, e um Módulo para prover funcionalidades ALE (Application Level Events). O EMS (Event Management System), o TMS (Task Management System) e o RIED (Real-time In-memory Event Database) da Referência de Implementação 1.0 do Savant poderão tornarem-se também um ou mais Módulos de Processamento Padrões.
6.6.1 Módulo de Processamento Padrão autoid.core
O módulo de Processamento Padrão autoid.core provê um conjunto mínimo de comandos da Interface de Aplicações, que permitem que aplicações saibam informações da identidade do Savant, o que outros Módulos de Processamento podem disponibilizar e também algumas funções de gerenciamento do Savant É um conjunto mínimo que todas as implementações de Savant devem suportar. O Módulo de Processamento Padrão autoid.core é um Módulo de Processamento REQUERIDO.
6.6.1.1
Mensagem GetSavantID
Uma aplicação externa envia uma mensagem autoid.core.GetSavantID para solicitar ao Savant o seu número de identificação único (no caso mais provável, um código EPC). Sistemas compatíveis DEVEM implementar esse comando.
|
Mensagem |
Campo |
Tipo |
Descrição |
|
Requisição GetSavantID |
Nenhum |
|
Essa função não possui parâmetros |
|
Resposta Normal GetSavantID |
SavantID |
String |
Uma string de identificação única do Savant.A string pode ser um código EPC. |
|
Resposta de Erro GetSavantID |
Error Code |
Int |
Código de Erro |
|
Resposta de Erro GetSavantID |
Error String |
String |
Descrição do Erro |
Tabela 6.1 Mensagens referentes ao comando GetSavantID Fonte: EPCglobal
6.6.1.2
Mensagem GetCapabilities
Uma aplicação externa envia uma mensagem autoid.core.GetCapabilities para solicitar ao Savant uma lista de todos os módulos de processamento configurados. Sistemas compatíveis DEVEM implementar esse comando.
|
Mensagem |
Campo |
Tipo |
Descrição |
|
Requisição GetCapabilities |
Nenhum |
|
Essa função não possui parâmetros |
|
Resposta Normal GetCapabilities |
Capabilities |
String [vetor] |
Uma representação em um vetor dos nomes dos módulos de processamento configurados no Savant.No mínimo,o vetor terá os módulos de processamento padrões requeridos. |
|
Resposta de Erro GetCapabilities |
Error Code |
Int |
Código de Erro |
|
Resposta de Erro GetCapabilities |
Error String |
String |
Descrição do Erro |
Tabela 6.2 Mensagens referentes ao comando GetCapabilities Fonte: EPCglobal
6.6.1.3
Mensagem Shutdown
Uma aplicação externa envia uma mensagem autoid.core.GetShutdown para requisitar ao Savant que este notifique a todos os subsistemas que eles devam ser desligados, e então o módulo de processamento core irá também ser desligado. Sistemas compatíveis DEVEM implementar esse comando.
|
Mensagem |
Campo |
Tipo |
Descrição |
|
Requisição Shutdown |
Nenhum |
|
Essa função não possui parâmetros |
|
Resposta Normal Shutdown |
Shutdown |
Boolean |
“True” se todos os sistemas foram notificados e “False” caso contrário |
|
Resposta de Erro Shutdown |
Error Code |
Int |
Código de Erro |
|
Resposta de Erro Shutdown |
Error String |
String |
Descrição do Erro |
Tabela 6.3 Mensagens referentes ao comando Shutdown Fonte: EPCglobal
6.6.1.4
Mensagem ResetAll
Uma aplicação externa envia uma mensagem autoid.core.ResetAll para informar ao Savant que este deve notificar a todos os subsistemas que eles devam ser reinicializados com suas configurações padrões, e assim o módulo de processamento core irá também ser reinicializado. É similar a um boot warm.Sistemas compatíveis DEVEM implementar esse comando.
|
Mensagem |
Campo |
Tipo |
Descrição |
|
Requisição ResetAll |
Nenhum |
|
Essa função não possui parâmetros |
|
Resposta Normal ResetAll |
ResetAll |
Boolean |
“True” caso todos os sistemas tenham sido notificados e “False” caso contrário |
|
Resposta de Erro ResetAll |
Error Code |
Int |
Código de Erro |
|
Resposta de Erro ResetAll |
Error String |
String |
Descrição do Erro |
Tabela 6.4 Mensagens referentes ao comando ResetAll Fonte:
EPCglobal
6.6.2 Módulo de Processamento Padrão autoid.readerproxy
O Módulo de Processamento Padrão autoid.readerproxy provê um conjunto mínimo de comandos da Interface de Aplicações que permitem à aplicações externas requisitar informações de quais leitores estão conectados e configurados para interagirem com o Savant, e prover um mecanismo para passar comandos diretamente a um leitor de forma individual.É um conjunto mínimo que cada implementação de Savant DEVE suportar. O Módulo de Processamento Padrão autoid.readerproxy é um Módulo REQUERIDO.
6.6.2.1
Mensagem GetReaders
Uma aplicação externa envia uma mensagem autoid.readerproxy.GetReaders para interrogar ao Savant por todos os leitores que estão configurados para se comunicarem. O Savant DEVE retornar todos os leitores que estão configurados através da especificação ReaderProtocolv1.1. Um Savant PODE retornar leitores que estão se comunicando com o Savant através de um meio não padronizado. Sistemas compatíveis DEVEM implementar esse comando.
|
Mensagem |
Campo |
Tipo |
Descrição |
|
Requisição GetReaders |
Nenhum |
|
Essa função não possui parâmetros |
|
Resposta Normal GetReaders |
Readers |
String [vetor] |
Vetor com todos os IDs de Leitores que o Savant está configurado para se comunicar. |
|
Resposta de Erro GetReaders |
Error Code |
Int |
Código de Erro |
|
Resposta de Erro GetReaders |
Error String |
String |
Descrição do Erro |
Tabela 6.5 Mensagens referentes ao comando GetReaders Fonte:
EPCglobal
6.6.2.2
Mensagem RunCommand
Uma aplicação externa envia uma mensagem autoid.readerproxy.RunCommand ao Savant como uma forma de passagem de comandos disparados através de aplicações externas aos leitores RFID.Desta forma, essas aplicações podem tirar vantagem de todos os comandos que um leitor RFID pode expor. Sistemas compatíveis DEVEM implementar esse comando.
|
Mensagem |
Campo |
Tipo |
Descrição |
|
Requisição RunCommand |
ReaderID |
String |
O ID do Leitor para onde o comandos é destinado |
|
Command |
String |
O nome do comando |
|
|
Argumentos |
String |
O conjunto de argumentos (parâmetros) necessários à execução do comando no leitor. Isso pode incluir uma string de tamanho variável separada por vírgula com um caractere de terminação nula UTF8.A estrutura detalhada dos argumentos é definida na especificação MTB and ReaderProtocol 1.0. |
|
|
Resposta Normal RunCommand |
RunCommand |
String |
A saída do leitor baseada na execução do comando.A resposta pode ser vazia, indicando que não houve resposta do leitor |
|
Resposta de Erro RunCommand |
Error Code |
Int |
Código de Erro |
|
Resposta de Erro RunCommand |
Error String |
String |
Descrição do Erro |
Tabela 6.6 Mensagens referentes ao comando RunCommand Fonte: EPCglobal
6.7
Interface de Aplicações – Messaging /
Transport Bindings (MTBs)
Esse sub-capítulo define as MTBs (Messaging/Transport Bindings) para a Interface de Aplicações.
Uma implementação de Savant DEVE suportar uma das MTBs de Interface de Aplicações definidas neste sub-capítulo.Como por enquanto há apenas duas MTBs definidas na Versão 1.0 da especificação do Savant, este requisito significa dizer que uma implementação de Savant DEVE suportar ou a MTB XML-RPC / HTTP definida no sub-capítulo 6.7.1) ou a MTB SOAP-RPC / HTTP (definida no sub-capítulo 6.7.2).
6.7.1 MTB XML-RPC / HTTP
Essa MTB carrega mensagens XML-RPC sobre TCP utilizando o protocolo HTTP 1.1. O objetivo dessa MTB é que se permita às aplicações comerciais de software um meio simples e aberto para as trocas de dados em rede baseadas em XML.
Pelo fato do HTTP ser um protocolo estritamente baseado em requisição / reposta, a mesma conexão não pode ser usada para ambos os Canais de Controle e Notificação. Nessa MTB, uma conexão HTTP (inicializada pela Aplicação) é utilizada para carregar o Canal de Controle, enquanto outra conexão HTTP (inicializada pelo Savant) é utilizada quando é necessário carregar o Canal de Notificação de maneira assíncrona.Abaixo segue uma lista de exemplos de possíveis tags e seus tipos de dados associados no corpo da mensagem XML.
|
Tag |
Tipo |
Exemplo(s) |
|
<int> |
Inteiro de quatro bytes,ou seja, um inteiro na faixa -231 ≤ x < 231 |
-42 |
|
<boolean> |
0 (false) 1 (true) |
1 |
|
<string> |
String |
Hello world |
|
<dateTime.iso8601> |
Data/hora no formato ISSO 8601, incluindo o timezone |
1998-07-17T14:08:55-05:00 |
|
<struct> |
Uma <struct> contém <members> e cada <member> contém um <name> e um <value> |
|
|
<array> |
Um <array> contém um único elemento <data> ,que pode conter qualquer número de <value>s |
|
Tabela 6.7 Exemplos de tags XML e seus respectivos tipos associados Fonte: EPCglobal
XML-RPC define um modo muito simples e fácil de se implementar mecanismos para proceder chamadas à módulos de processamento em uma rede.A primeira versão da especificação do Savant é ainda muito básica, com a expectativa que as próximas versões possam ser mais ricas quanto às suas características, e por isso a utilização de XML-RPC torna-se conveniente para as definições e invocações atuais dos Módulos de Processamento Padrões requeridos. Ele não define mapeamentos reais para qualquer linguagem de programação em particular, e sua representação é inteiramente independente de plataforma, o que por sinal é outro objetivo da versão 1.
A versão atual da especificação XML-RPC é mapeada no topo de um pedido de post HTTP e, sabendo-se que o HTTP 1.1 é onipresente e muito simples de ser implementado, ele é o protocolo escolhido para o uso nesta MTB.Além disso, as características inerentes ao HTTP de requisição / resposta provêm uma solução eficiente para a implementação do modelo de requisição / resposta utilizado no Canal de Controle.
6.7.1.1
Requisições em Canais de Controle
Uma mensagem XML-RPC é uma requisição HTTP-POST. O corpo (body) da requisição é em XML. Uma função (procedure) é executada no servidor e o valor que ela retorna também é formatado em XML.
Os parâmetros das funções podem ser escalares, números, strings, datas, etc.; e podem também ser registros complexos e outras estruturas, como listas, por exemplo.O número da porta do Canal de Controle DEVERIA ser configurável durante sua instalação. A porta default DEVE ser a porta 8080.O formato da requisição deve se parecer com o mostrado abaixo:
POST /Savant/ApplicationInterface HTTP/1.1
User-Agent: [Some
Host: mycompany.example.org
Content-Type: text/xml
Content-length: 181
<?xml version="1.0"?>
<methodCall>
<methodName>autoid.core.GetSavantID</methodName>
</methodCall>
O valor do elemento XML-RPC methodName é formado pela concatenação do nome do Módulo de
Processamento, um caractere ponto, e o nome da operação definida por aquele
módulo de processamento.
6.7.1.2
Respostas em Canais de Controle
As respostas XML-RPC são similares às requisições, sendo consistida de um cabeçalho HTTP 1.1 com um corpo XML como conteúdo.Abaixo segue um exemplo:
HTTP/1.1 200 OK
Connection: close
Content-Length: 158
Content-Type: text/xml
Date:
Server: [Some
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value>
<string>
urn:epc:1:2.24.400</string>
</value>
</param>
</params>
</methodResponse>
6.7.1.3
Especificação de Mensagens para o Módulo Core
Abaixo segue o detalhamento de mensagens AI suportadas pelo Módulo de Processamento Padrão autoid.core. Tratam-se de três exemplos de mensagens XML-RPC para o comando GetSavantID (requisição, resposta normal e resposta de erro).
Nota:De forma similar, os outros comandos relacionados ao Módulo Core (GetCapabilities, Shutdown e ResetAll) são também formatados e apresentados em mensagens XML-RPC, seguindo as mesmas características do exemplo mostrado a seguir.
Exemplo de Requisição (GetSavantID):
<?xml version="1.0"?>
<methodCall>
<methodName>autoid.core.GetSavantID</methodName>
</methodCall>
Exemplo de Resposta Normal(GetSavantID):
<?xml
version="1.0"?>
<methodResponse>
<params>
<param>
<value>
<string>urn:epc:1:2.24.400</string>
</value>
</param>
</params>
</methodResponse>
Exemplo de
Resposta de Erro (GetSavantID):
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>ErrorCode</name>
<value><int>1</int></value>
</member>
<member>
<name>ErrorString</name>
<value><string>SAVANT_AI_ERROR_1.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
6.7.1.4
Especificação de Mensagens para o Módulo ReaderProxy
Abaixo
segue o detalhamento de mensagens AI suportadas pelo Módulo de Processamento
Padrão autoid.readerproxy. Tratam-se
de três exemplos de mensagens XML-RPC para o comando RunCommand (requisição, resposta normal e resposta de erro).
Nota:De forma similar, o outro comando relacionado ao Módulo ReaderProxy (GetReaders) é também formatado e apresentado em mensagens XML-RPC, seguindo as mesmas características do exemplo mostrado a seguir.
Exemplo de Requisição (RunCommand):
<?xml version="1.0"?>
<methodCall>
<methodName>autoid.readerproxy.RunCommand</methodName>
<params>
<param>
<struct>
<member>
<name>ReaderID</name>
<value><string>urn:epc:1.2.24.401</string></value>
</member>
<member>
<name>Command</name>
<value><string>GetTagList</string></value>
</member>
</struct>
</param>
</params>
</methodCall>
Exemplo de Resposta Normal (RunCommand):
<?xml
version="1.0"?>
<methodResponse>
<params>
<param>
<value>
<array>
<data>
<value><string>urn:epc:1:2.30.333</string></value>
<value><string>urn:epc:1:2.30.334</string></value>
<value><string>urn:epc:1:2.30.335</string></value>
<value><string>urn:epc:1:2.30.336</string></value>
</data>
</array>
</value>
</param>
</params>
</methodResponse>
Exemplo de Resposta de Erro (RunCommand):
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>ErrorCode</name>
<value><int>6</int></value>
</member>
<member>
<name>ErrorString</name>
<value><string>SAVANT_AI_ERROR_6.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
6.7.2 MTB SOAP-RPC/HTTP
Essa MTB carrega mensagens SOAP RPC sobre TCP utilizando o protocolo HTTP 1.1. O objetivo dessa MTB é que se permita às aplicações comerciais de software um meio simples e aberto para as trocas de dados SOAP RPC baseadas em XML.
SOAP é um paradigma de troca de mensagens para trocas estruturadas e envio de informações entre nós em um ambiente distribuído e descentralizado. Ele provê uma estrutura pela qual os dados específicos das aplicações podem ser transportados de maneira extensível.
O modelo SOAP define uma representação uniforme para requisições e repostas RPC e facilita a troca de mensagens, que são mapeadas convenientemente de acordo com as definições e invocações de métodos e procedures. Ele não define mapeamentos para uma linguagem de programação em particular , e sua representação é inteiramente independente de plataforma.
SOAP-RPC pode ser implementado independente de qualquer protocolo de transporte em particular , mas desde que o HTTP 1.1 é onipresente e de fácil implementação, ele é o protocolo escolhido para ser utilizado nessa MTB. Além disso, as características de requisição e reposta do HTTP disponibilizam uma solução eficiente para a implementação de modelos de requisição / reposta ocorridos no Canal de Controle.
Pelo fato do protocolo HTTP ser estritamente de requisição / resposta , a mesma conexão não pode ser utilizada para ambos os Canais de Controle e Notificação. Nessa MTB, uma conexão HTTP (iniciada pela Aplicação) é utilizada para transportar os dados dentro do Canal de Controle, enquanto outra conexão HTTP (iniciada pelo Savant), é utilizada quando for necessário carregar o Canal de Notificação de maneira assíncrona.
6.7.2.1
Savant e Aplicações Comerciais como um nó SOAP
A interação entre o Savant e aplicações comercias de software serão implementadas como trocas (exchange) SOAP RPC. O Savant e a aplicação correspondente na troca de mensagens irão se comportar como um nó SOAP , necessitando expor uma interface SOAP RPC utilizando o protocolo HTTP. Como o módulo SOAP é integrado ao Savant e às aplicações comerciais é irrelevante do ponto de vista da MTB , sendo que o que realmente importa é que eles possam expor uma interface SOAP para trocas externas de mensagens entre si. No restante desse sub-capítulo, o termo “nó SOAP” será usado como uma referência genérica para o Savant e uma aplicação comercial que implemente essa MTB.
Figura 6.4 Mensagens SOAP RPC Fonte: EPCglobal
6.7.2.2
Mensagens AI
Esta MTB prescreve mensagens SOAP RPC formatadas em XML como o conteúdo de informações dos Canais de Controle e Notificação, trocadas entre os nós SOAP. Para as Mensagens do Canal de Controle, a aplicação comercial da empresa é o nó SOAP remetente e o Savant é o nó SOAP destinatário; e vice-versa para Mensagens do Canal de Notificação.
A mensagem SOAP, quando recebida pelo destinatário SOAP, deve ser despachada para o módulo de processamento apropriado, e a interface padrão apropriada deve ser invocada. A mensagem SOAP precisa conter informações suficientes para que o destinatário SOAP esteja apto a fazer isso. Se a mensagem SOAP processada é uma requisição do Canal de Controle, então a resposta correspondente também precisa ser retornada para o remetente SOAP. Assim, parâmetros padrões RPC precisam ser definidos para que o destinatário RPC esteja apto a se comunicar com o Módulo de Processamento Padrão. O sub-capítulo 6.6 declara os Módulos de Processamento Padrões e define as mensagens suportadas por eles. Essa MTB provê representações SOAP RPC dos parâmetros das mensagens que precisam ser utilizadas para a comunicação com os Módulos de Processamentos Padrões. Essas mensagens SOAP que contêm os parâmetros padrões RPC são chamadas de Mensagens AI.
Os sub-capítulos seguintes mostram os detalhes atuais de implementação desta MTB em particular. Essencialmente, eles mostram as regras para a formatação de mensagens SOAP e da construção RPC para as mensagens AI. Na continuidade deste capítulo, o termo “Mensagens AI” será utilizado como uma referência específica para as Mensagens SOAP XML dos Canais de Notificação e Controle, formatadas em SOAP RPC e trocadas entre dois nós SOAP.
6.7.2.3
Regras
para Implementações SOAP
Conforme citado no sub-capítulo 6.7.2.1, o Savant e as aplicações comerciais de software comportam-se como nós SOAP em uma troca de mensagens. Esse sub-capítulo identifica características SOAP específicas que são requeridas na implementação de um nó SOAP. A especificação versão 1.2 do SOAP possuí muitas funcionalidades que são opcionais e não requeridas para sua implementação. Implementações desta MTB requerem uma implementação do SOAP que implemente também algumas dessas facilidades opcionais. As seguintes regras SOAP DEVEM ser implementadas em uma implementação SOAP compatível com essa MTB (SOAP-RPC) :
1. A implementação SOAP DEVE seguir a versão 1.2 das especificações SOAP.
2. A implementação SOAP DEVE implementar a codificação SOAP conforme descrito na Seção 3 – “SOAP Encoding” do documento da W3C “SOAP 1.2 part 2:Adjuncts” , que é identificado pela URI “http://www.w3.org/2003/05/soap-encoding”.
3. A implementação SOAP DEVE implementar a representação SOAP RPC conforme descrito na Seção 4 – “SOAP RPC Representation” do documento da W3C “SOAP 1.2 part 2:Adjuncts” , que é identificado pela URI “http://www.w3.org/2003/05/soap-rpc”.
4. A implementação SOAP DEVE implementar o modelo SOAP HTTP conforme descrito na Seção 7 – “SOAP HTTP Binding” do documento da W3C “SOAP 1.2 part 2:Adjuncts” , que é identificado pela URI “http://www.w3.org/2003/05/soap/bindings/HTTP”.
6.7.2.4
Especificação para Objetos-Alvo URI
Esse sub-capítulo especifica um mecanismo padrão para o endereçamento de Módulos de Processamento Padrões em um dado nó SOAP. Para essa MTB em particular, o servidor Savant é o nó SOAP que expõe uma interface de serviço SOAP RPC sobre HTTP. Os Módulos de Processamento Padrões declarados no sub-capítulo 6.6 podem assim ser identificados como recursos web no servidor Savant. Esse módulos expõe interfaces de serviços bem definidas que podem ser invocadas para que sejam retiradas informações de estados ou para modificar algum estado que as pertença. As chamadas SOAP RPC de clients DEVEM ser dirigidas a esse módulos no servidor Savant para o processamento via serviços SOAP RPC.
Como já mencionado, os Módulos de Processamento Padrões podem ser identificados como recursos web. Esses recursos serão os alvos das chamadas SOAP RPC de algum client. Os Módulos de Processamento Padrões como recursos web no servidor Savant podem assim serem expostos através de um serviço SOAP RPC, como um objeto-alvo das chamada SOAP RPC de clients. Em outras palavras, um Módulo de Processamento Padrão pode ser entendido como um serviço SOAP RPC no servidor Savant. Cada serviço em um determinado servidor é identificado através de uma URI, geralmente chamada de ‘URI de objeto-alvo’, e é chamada de forma que a URI é o objeto-alvo da chamada de um client. URNs padrões podem ser utilizadas para o objeto-alvo URI. Abaixo segue a definição de URNs padrões chamadas de “Service URN” que DEVEM ser utilizadas como objeto-alvo URI para o serviço correspondente a um Módulo de Processamento Padrão no servidor Savant.
|
Nome do Módulo de
Processamento Padrão |
Service URN |
|
autoid.core |
urn:autoid:specification:interchange:Savant:core:xml:service:1 |
|
autoid.readerproxy |
urn:autoid:specification:interchange:Savant:readerproxy:xml:service:1 |
Tabela 6.8 Services URNs Fonte: EPCglobal
As Services URN citadas acima foram construídas seguindo os princípios de design de namespaces descritos na especificação PML Core(que será descrita no próximo capítulo). A estrutura do namespace specific scheme(NSS) que parte do namespace ID ‘autoid’ (NID) possui uma hierarquia de especificação de subclasse(specification-subclass)
e de especificação de ID (specification-ID). As URNs de serviço citadas na tabela 6.8 foram formuladas através da identificação ‘Savant’ como um valor para a hierarquia de especificação de subclasse, e pelo mapeamento mecânico do nome do Módulo de Processamento Padrão como o valor para a hierarquia de especificação de ID. Essa abordagem DEVE ser seguida para a construção de uma Service URN de serviço correspondente a qualquer Módulo Padrão de Processamento.
Para Módulos de Processamento não-Padrões, a entidade que irá definir o módulo PODE utilizar a mesma abordagem citada acima para a definição de uma Service URN. Isso PODERIA estar em um namespace específico do criador do Módulo de Processamento não-Padrão.
A URL de destino do serviço é a locação do serviço SOAP RPC identificado pelo objeto-alvo URI, mutuamente acordado entre o remetente SOAP e o destinatário SOAP.A URL utilizada para a chamada SOAP RPC de client é comumente chamada de action URL. A action URL para a chamada SOAP RPC de um client será então a concatenação da URL destino de serviço e o objeto-alvo URI. Para a requisição HTTP adjacente, o objeto-alvo URI será parte da requisição URI formatada para invocar o serviço SOAP RPC. As chamadas SOAP RPC de clients devem então ser despachadas aos Módulos de Processamento Padrões no servidor Savant que estão identificados nessas Services URNs.
Abaixo segue um exemplo que ilustra isso:
POST
/urn:autoid:specification:interchange:Savant:core:xml:service:1 HTTP/1.1
Host: mycompany.example.org
Content-Type: application/soap+xml;
charset="utf-8"
Content-Length: nnnn
<?xml version='1.0'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Body>
<!-- Standard SOAP RPC’s for Savant AI embedded
here -->
</env:Body>
</env:Envelope>
6.7.2.5
Arquitetura de Esquemas AI
Conforme descrito no sub-capítulo 6.7.2.2, as mensagens AI são mensagens SOAP RPC. De acordo com a especificação SOAP, os parâmetros RPC são incluídos no elemento Body do Envelope SOAP. A versão 1.2 do SOAP permite fortemente a inserção desses parâmetros RPC através da disponibilização da funcionalidade de defini-los em uma sintaxe de Esquemas (schemas) XML. Por isso, os parâmetros RPC para as mensagens AI estão definidos em Esquemas XML. Mensagens AI são categorizadas a partir do seu Módulo de Processamento Padrão respectivo, ou seja , que o processa. Desta forma, é disponibilizado um Esquema XML correspondente a cada Módulo de Processamento Padrão definido na especificação do Savant. Cada esquema contém a definição dos parâmetros RPC SOAP correspondentes às mensagens AI que podem ser processadas pelo módulo. Os esquemas seguem a metodologia de design descrita na especificação PML Core.
A especificação de mensagens AI consiste do 3 esquemas AI definidos abaixo:
1. Core.xsd : Contém definições das mensagens suportadas pelo Módulo de Processamento Padrão autoid.core.
2. ReaderProxy.xsd : Contém definições das mensagens suportadas pelo Módulo de Processamento Padrão autoid.readerproxy.
3. Error.xsd : Contém definições de tipos de domínios reutilizáveis de Savant que são reutilizados pelos tipos dos 2 esquemas anteriores.
Para essa especificação, os documentos de esquemas XML listados abaixo são normativos para os seguintes namespaces :
|
Namespace |
Nome do Arquivo |
|
urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1 |
Core.xsd |
|
urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1 |
ReaderProxy.xsd |
|
urn:autoid:specification:domain:Savant:Error:xml:soap-rpc:1 |
Error.xsd |
Tabela 6.9 URNs de Serviço versus Esquemas XML Fonte: EPCglobal
A locação dos documentos normativos de esquemas XML referente às especificações versão 1.2 do SOAP está especificada na Seção 1 da especificação SOAP 1.2 part 1: Messaging Framework. Cópias locais desses documentos de esquemas estão disponibilizadas para referências. O esquema SOAP descrito abaixo foi referenciado pelos esquemas AI :
1. soap-rpc.xsd: Contém definições dos parâmetros SOAP RPC. O elemento SOAP RPC “result” é referenciado nos esquemas AI.
O package de esquemas para esta especificação inclui adicionalmente os documentos de esquemas XML soap-envelope.xsd e soap-encoding.xsd , que fazem parte originalmente das especificações oficiais SOAP , parte 1 e parte2 respectivamente. Embora os esquemas AI não o requiram, eles PODEM ser utilizados para a validação local de uma mensagem SOAP.
Figura 6.5 Esquemas xsd XML AI Fonte: EPCglobal
Os esquemas AI listados acima são normativos para os Módulos de Processamento Padrões definidos na especificação atual do Savant e DEVEM ser implementados por um Savant compatível. Para Módulos de Processamento não-Padrões, a(s) entidade(s) que os definiram PODEM utilizar uma arquitetura similar à citada acima para os esquemas que definem as mensagens AI suportadas pelo Módulo em consideração. As URIs de namespaces alvos para os esquemas PODERIAM ser definidas em uma namespace próprio do criador do Módulo de Processamento não-Padrão.
6.7.2.6
Especificação de Mensagens para o Módulo Core
As mensagens AI suportadas pelo Módulo de Processamento Padrão autoid.core estão definidas no esquema Core.xsd.
Tratam-se de três exemplos de mensagens SOAP-RPC para o comando GetSavantID (requisição, resposta normal e resposta de erro). A mensagem de requisição GetSavantID é implementada através do elemento GetSavantID.
Nota: De forma similar, os outros comandos relacionados ao Módulo Core (GetCapabilities, Shutdown e ResetAll) são também formatados e apresentados em mensagens SOAP-RPC, seguindo as mesmas características do exemplo mostrado a seguir.
Exemplo de Requisição (GetSavantID):
<?xml version="1.0"
encoding="UTF-8"?>
<core:GetSavantID xmlns:core="urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1
../SchemaFiles/Interchange/Core.xsd"/>
Exemplo de Resposta Normal(GetSavantID):
<?xml version="1.0" encoding="UTF-8"?>
<core:GetSavantIDResponse xmlns:core="urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1
../SchemaFiles/Interchange/Core.xsd">
<rpc:result>core:SavantID</rpc:result>
<core:SavantID>urn:epc:1:2.24.400</core:SavantID>
</core:GetSavantIDResponse>
Exemplo de Resposta de Erro (GetSavantID):
<?xml version="1.0" encoding="UTF-8"?>
<core:GetSavantIDError xmlns:core="urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1" xmlns:err="urn:autoid:specification:domain:Savant:Error:xml:soap-rpc:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1
../SchemaFiles/Interchange/Core.xsd">
<err:ErrorCode>1</err:ErrorCode>
<err:ErrorString>GET_SAVANT_ID_ERROR</err:ErrorString>
</core:GetSavantIDError>
6.7.2.7
Especificação de Mensagens para o Módulo ReaderProxy
As mensagens AI suportadas pelo Módulo de Processamento Padrão autoid.readerproxy estão definidas no esquema ReaderProxy.xsd.
Tratam-se de três exemplos de mensagens SOAP-RPC para o comando RunCommand (requisição, resposta normal e resposta de erro).A mensagem de requisição RunCommand é implementada através do elemento RunCommand.
Nota:De forma similar, o outro comando relacionado ao Módulo ReaderProxy (GetReaders) é também formatado e apresentado em mensagens SOAP-RPC, seguindo as mesmas características do exemplo mostrado a seguir.
Exemplo de Requisição (RunCommand):
<?xml version="1.0" encoding="UTF-8"?>
<rpx:RunCommand xmlns:rpx="urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1
../SchemaFiles/Interchange/ReaderProxy.xsd">
<rpx:ReaderID>urn:epc:1:2.24.500</rpx:ReaderID>
<rpx:Command>READER_COMMAND</rpx:Command>
<rpx:Arguments>ARG1,ARG2,ARG3</rpx:Arguments>
</rpx:RunCommand>
Exemplo de Resposta Normal(RunCommand):
<?xml version="1.0" encoding="UTF-8"?>
<rpx:RunCommandResponse xmlns:rpx="urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1
../SchemaFiles/Interchange/ReaderProxy.xsd">
<rpc:result>rpx:RunCommand</rpc:result>
<rpx:RunCommand>SUCCESS</rpx:RunCommand>
</rpx:RunCommandResponse>
Exemplo de Resposta de Erro (RunCommand):
<?xml version="1.0" encoding="UTF-8"?>
<rpx:RunCommandError xmlns:rpx="urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:err="urn:autoid:specification:domain:Savant:Error:xml:soap-rpc:1" xsi:schemaLocation="urn:autoid:specification:interchange:Savant:readerproxy:xml:soap-rpc:1
../SchemaFiles/Interchange/ReaderProxy.xsd">
<err:ErrorCode>1</err:ErrorCode>
<err:ErrorString>RUN_COMMAND_ERROR</err:ErrorString>
</rpx:RunCommandError>
|
Capitulo 7 |
Physical Markup Language (PML) |
A Physical Markup Language(PML) é uma coleção de vocabulários XML padronizados para representar e distribuir informações a objetos relacionados em Sistemas de Auto- Identificação.
O Desenvolvimento da PML é dividido em esforços paralelos.
PML Core:
A PML Core está sendo desenvolvida Pelo Auto-Id Center e EPC Global e fornece um formato padronizado para troca de dados capturados em sistemas de auto identificação
PML Extensions:
A PML Extensions será desenvolvida por indústrias e deverá fornecer extensões especificas que ofereçam suporte as industrias.
O objetivo da PML Core é padronizar o conteúdo das mensagens enviadas dentro de uma rede EPC. O desenvolvimento do Padrão PML Core faz parte de um projeto para a padronização de interfaces e protocolos para comunicações que usam redes de Auto- Identificação.
A PML Core fornece um formato padrão para troca de dados que são capturados por sensores, como leitores de RFID, dentro de uma arquitetura de auto-identificação, fazendo com que mensagens baseadas no esquema PML Core possam ser trocadas entre sistemas em uma rede EPC.
A especificação PML Core 1.0 define a sintática e a semântica da Linguagem.
Figura
7.1: Padrões em desenvolvimento Fonte: EPCglobal
7.1 Descrição geral e cenários de uso
O objetivo desta seção é analisar e demonstrar quando os recursos da PML Core são necessários.
A especificação 1.0 da PML Core não faz recomendações de como os dados enviados em uma rede EPC devem ser armazenados. Serviços como os do Savant não necessitam armazenar os dados no formato definido pela PML Core. O formato PML Core necessita ser usado somente quando os dados forem trocados entre os componentes da rede EPC.
A linguagem PML Core fornece uma sintaxe comum para a troca de dados em uma rede EPC e para troca de dados entre componentes da uma rede EPC e aplicações externas .
Os vocabulários da PML Core devem fornecer recursos que sejam necessários para compreender a troca de dados entre:
o Um sensor, como um leitor RFID e um Servidor Savant.
o Um Servidor Savant/EPC e uma aplicação externa.
o Um servidor Savant conectado a sensores e outros Servidores Savant.
Para que sejam utilizados os recursos da PML Core, os componentes que constituem o ambiente devem permitir integração com XML.
A PML Core também prevê a utilização em conjunto com outras tecnologias e componentes dentro de um ambiente de auto-identificação, podendo integrar Leitores RFID e leitores de códigos de barras.
7.2 Características gerais da PML Core
Uso dos padrões existentes: O uso dos padrões existentes para descrever e definir entidades individuais como datas é recomendável sempre que possível. A utilização dos padrões também se aplicam para a nomeação e definição de regras e para a escolha de uma de uma arquitetura em particular.
A utilização dos padrões existentes assegura velocidade no
desenvolvimento, melhora a interoperabilidade e facilita a manutenção a longo
prazo. O uso dos padrões também asseguram o foco da PML , para que não sejam
incluídas características que não estão definidas na PML Core 1.0.
Rigidez: A linguagem foi descrita de uma maneira que a estrutura e o conteúdo dos documentos sejam restritos.
Usar estritamente as regras especificadas permite o uso de analisadores que checam a validade de todo o conteúdo de um documento. Isso deve prevenir uma série de problemas vistos com o HTML que não obriga a aderência de sintaxe rígida, deixando para o desenvolvedor do navegador decidir que tipo de violações de sintaxe ele irá aceitar.
Simplicidade: A simplicidade é um meio para que o uso e a implementação da linguagem seja simples e claro.
Para encorajar o uso das tecnologias desenvolvidas pelo Auto-ID a linguagem PML Core deve ser o mais simples e clara o possível.
Não suposição de um protocolo de transporte: Durante projetos e implementações, nenhum protocolo de transporte precisa ser especificado para os dados que trafegarem através dos nós da rede EPC.
Não determinando um protocolo de transporte, permite-se a escolha de um protocolo apropriado em um estágio posterior do projeto, sem que uma escolha inicial faça restrições durante todo o projeto e durante a implementação da PML Core.
Permitir a compreensão do código: Permitir a leitura e entendimento dos campos de dados por pessoas, ao menos que sejam escolhidos nomes, que devem ser secretos ou encriptados.
A razão para facilitar a leitura por pessoas, é que desta maneira se aumenta a curva de compreensão da linguagem o que simplifica o processo de depuração, sendo que atualmente é comum o desenvolvimento de padrões XML. A desvantagem de tornar o código compreensível é que a medida que os dados tem mais significado para as pessoas, mais dados terão que ser transferidos. A segurança da rede não é um motivo preocupante atualmente já que o volume de dados contido em tags não são suficientemente grandes para justificar a de encriptação dessas informações.
Disponibilidade de ferramentas para verificação da linguagem e distribuição: A PML Core não restringe a utilização de determinadas ferramentas para seu desenvolvimento, gerenciamento, armazenamento ou apresentação. Para a fácil adoção da PML não se deve restringir o uso de ferramentas especificas, deixando isso a cargo dos usuários.
O desenvolvimento e uso de ferramentas que manipulam a PML devem ser estimulados, já que para fazer uso da PML o usuário precisará contar com ferramentas que verificam a sintaxe especifica da linguagem para validação de conteúdo e esquemas.
Facilitar ao máximo o reuso de componentes: A linguagem é definida para possibilitar o máximo reuso de componentes em diferentes contextos. Pensando no reuso de componentes, a PML pode construir blocos que tem a possibilidade de serem reutilizados em contextos que não haviam sido imaginados anteriormente.
Regra 80/20: As especificações da PML são desenvolvidas de maneira que 20% dos recursos da linguagem são suficientes para 80% de tudo que é necessário.
Como já mencionado, a PML deve ter um design simples, a inclusão de muitos recursos especiais que serão utilizados por poucos usuários tornaria o vocabulário complexo e de difícil utilização.
Intenções de uso: A PML tem como intenção de uso o intercambio de dados e uso em aplicações, sem assumir ou fazer recomendações sobre como os dados serão realmente armazenados fisicamente. O objetivo da PML Core é padronizar como os dados que são capturados em uma rede EPC devem ser formatados. Supor um determinado mecanismo de armazenamento como bancos de dados XML, ameaçaria a adoção da PML, pois ao fazer a utilização da PML usuários estariam sendo forçados a adotar também as recomendações de armazenamento.
7.3 Tipos de dados que poderão ser
representados através da PML Core
Dados capturados por leitores RFID: Os leitores RFID captam o código eletrônico que estão armazenados em tags compatíveis. Assim, a PML deve ser capaz de representar este processo onde um determinado leitor RFID detecta informações contidas em tags de uma determinada faixa de leitura destinada para um leitor em um determinado momento.
Dados gerados em sensores montados em tags RFID: As próximas gerações de tags RFID irão conter sensores que farão observações sobre o ambiente em que estão expostos, como temperatura, umidade e até sensores de peso. Desta forma,a PML Core deverá ser capaz de formatar as informações recebidas através desses sensores. Cada observação feita pelos tags com sensores incorporados deverão ser distinguidas de acordo com o momento em que as leituras são efetuadas.
Dados capturados por sensores que não sejam RFID: Sensores como os leitores de código de barras que capturam informações similares as de sensores RFID também serão suportados na PML Core.
7.4 Arquitetura do esquema PML Core
A PML Core é um subconjunto da PML, e os esquemas da PML Core seguem a metodologia de desenvolvimento da PML.
As especificações da PML Core fornecem a nomenclatura, princípios de desenvolvimento e as praticas recomendadas para desenvolvimento utilizando a PML Core.
Visão geral sobre a metodologia de projetos com PML: A PML utiliza o W3C XML esquemas XSD para sua definição. Embora diferentes representações sintáticas possam ser usadas, esquemas XML bem definidos geralmente são um método simples para definição de dados em estruturas flexíveis. Qualquer projeto de vocabulário XML precisa ser documentado e bem definido para ter uma fácil compreensão, adoção e implementação. Uma metodologia XML bem definida descreve os princípios utilizados para arquitetar esquemas particulares de vocabulários.
Ao invés de criar uma própria metodologia de projetos XML, a PML faz uso de uma metodologia bem definida já existente em seu projeto. O projeto PML é baseado na metodologia XML definida pela RosettaNet.
Diretrizes para Namespaces: As URNs(Uniform Resource Names) são utilizadas para identificação de recursos na PML; e todos recursos da PML devem adotar e utilizar a estrutura para Namespaces descrita neste capitulo.
Hierarquia de Namespaces: Namespaces são formatados por URNs que tem uma estrutura hierárquica, e cada nível da hierarquia fornece informações adicionais sobre a as especificações de uma entidade que está sendo identificada pelo Namespace em questão. O Namespace ID (NID) é usado como um campo identificador de todos Namespaces.
Hierarquia de Especificações: Consistem de uma serie de especificações publicadas pelo Auto Id. As especificações podem pertencer a varias classes de especificações como Domínio, Universal, Transferência ou Intercâmbio, ou até mesmo de uma classe de especificação ainda não definida. As especificações podem ser Esquemas, documentos, publicações, etc.
Figura 7.2:
Hierarquia de especificações Fonte: EPCglobal
A hierarquia de especificações será descrita a seguir:
urn:autoid:especificação:{classe-de-especificação}:{subclasse-de-especificação?}:
{Id-da-especificação}:{Tipo}:{Subtipo}?{Id-do-documento}:{:Id-da-versão}
Onde:
classe-de-especificação
:: = domínio|universal|intercambio
Na classe de especificação se determina, por exemplo: o “domínio” que identifica que os recursos estão definidos em um domínio particular. “universal” identifica recursos que são universais no Namespace. “intercambio” Identifica recursos que são trocados dentro de um sistema de auto identificação como mensagens XML.
subclasse-de-especificação
::= Savant|Reader
A subclasse de especificação deve ser usada sempre que for necessária a identificação de subclasses dentro de uma classe de especificação.
Id-da-especificação
É o identificador de um recurso dentro da classe de especificação. Deve ser o mesmo nome existente nas subclasses ou na classe de especificação.
Tipo::= xml
É o tipo do recurso, deve ser de fácil entendimento e de simples compreensão. O valor do “tipo” deve ser ‘xml’ para todos recursos da PML.
Subtipo::=
esquema|soap-rpc|folha de estilos|serviço
O subtipo é uma opção para deixar mais especifico o tipo de recurso
Id-do-documento
É um identificador opcional para o documento em que o recurso está relacionado, deve ter o nome de um documento existente ou ser uma abreviação.
Id-da-versão::=
{versão principal}
|
Classe de especificação |
Subclasse de
especificação |
Id da especificação |
Tipo |
Subtipo |
Id do documento |
Id da versão |
|
universal |
|
Identifier |
xml |
schema |
|
1 |
|
interchange |
|
PMLCore |
xml |
schema |
|
1 |
|
interchange |
Savant |
core |
xml |
soap-rpc |
|
1 |
|
interchange |
Savant |
core |
xml |
Service |
|
1 |
|
interchange |
Savant |
readerproxy |
xml |
soap-rpc |
|
1 |
|
interchange |
Savant |
readerproxy |
xml |
Service |
|
1 |
Tabela 7.1: Valores válidos para os
campos Fonte: EPCglobal
Através dos valores apresentados na tabela 7.1 é possível construir URNs válidos que são utilizados nos esquemas da PML Core, como no exemplo:
urn:autoid:specification:interchange:PMLCore:xml:schema:1
urn:autoid:specification:interchange:Savant:core:xml:soap-rpc:1
7.5
Estrutura
de arquivos da PML Core
A especificação dos elementos da PML Core que veremos a seguir estão definidos no arquivo ‘PMLCore.xsd’, que será apresentado no sub-capítulo 7.7.
Como mencionado no Capitulo 7.3, a PML Core pode representar a troca de dados entre dois componentes de uma rede EPC que sejam compatíveis com XML. O esquema ‘PMLcore.xsd’ segue todas as diretrizes que foram especificadas anteriormente.
O ‘PMLCore.xsd’ importa o esquema PML ‘Identifier.xsd’ que é um esquema universal que define estruturas identificadoras da PML, não sendo restritos apenas a PML Core.
Figura 7.3: Estrutura de arquivos da PML
Core Fonte: EPCglobal
7.5.1
Modelagem
de Sensores na PML Core
A PML Core é baseada em um modelo em que um sensor ou algum tipo de observador faz uma observação de uma certa característica observável.
A modelagem de sensores na PML Core é uma estrutura flexível e genérica para a representação de sensores dentro de uma rede EPC.
Embora um leitor RFID seja um componente importante em uma rede EPC, na modelagem de sensores da PML Core os leitores RFID são considerados apenas como um tipo de sensor e não serão modelados explicitamente. Na modelagem da PML Core os leitores RFID serão tratados da mesma forma que sensores de temperatura, umidade, leitores de código de barras e outros dispositivos que possam representar um sensor, sem deixar uma estrutura especifica para sensores RFID, obrigando futuramente a criação de modelagens também especificas para outros tipos de sensores.
Figura 7.3:
Classificação aproximada dos sensores
Fonte: EPCglobal
Uma propriedade comum a todos sensores ou tags em uma rede EPC é que ele tenha uma identificação id. O id de um dispositivo por padrão deve ser um EPC, mas eles não são limitados a isso, sendo que os sensores podem ter também formulários proprietários de identificação.
7.6
Elementos
da PML Core
Como citado no capitulo 7.5, todos elementos da PML Core que serão apresentados estão definidos nos esquemas XML ‘PMLCore.xsd’ e Identifier.xsd que serão apresentados no capitulo 7.7.
7.6.1 Elemento ID
O elemento ID é um elemento do tipo Identifier que esta definido no esquema “Identifier.xsd”, que é uma estrutura universal usada também fora da PML Core. Em uma rede EPC, os sensores são identificados por um código de identificação, e por padrão o esquema de identificação deve ser o código eletrônico de produto EPC. Porém, atributos de identificação podem ser utilizados para especificar um esquema alternativo de identificação em algumas circunstâncias, desde que este esquema alternativo utilize atributos do tipo Identifier. Isto permite que desenvolvedores criem esquemas próprios de identificação, onde a estrutura do elemento ID é utilizada para capturar as informações de identificação do sensor e sua estrutura universal permite sua reutilização.
Exemplo de codificação para um elemento ID em XML:
<pmlcore: Sensor>
<pmluid:ID>urn:epc:1:4.16.36</pmluid:ID>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.400</pmluid:ID>
</pmlcore:Tag>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.401</pmluid:ID>
</pmlcore:Tag>
</pmlcore:Observation>
</pmlcore:Sensor>
7.6.2 Elemento Sensor
O elemento Sensor é o principal elemento de transferência de mensagens da PML Core. Este elemento compreende dois elementos subordinados:
o
Elemento ID.
o Um ou mais elementos de observação.
O elemento Sensor captura informações de sensores. Conforme citado no subcapítulo 7.5, um sensor é considerado qualquer dispositivo que realiza medições e observações. Na linguagem PML, o modelo para sensores não faz distinção entre um leitor RFID e um sensor de temperatura, exceto pelo fato de que eles possuem códigos de identificação distintos. Os diferentes códigos de identificação e informações que podem ser extraídas utilizando esse identificador permite às aplicações ganhos adicionais específicos no processo sensorial.
Exemplo de codificação para um elemento ID em XML:
<pmlcore: Sensor>
<pmluid:ID>urn:epc:1:4.16.36</pmluid:ID>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.400</pmluid:ID>
</pmlcore:Tag>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.401</pmluid:ID>
</pmlcore:Tag>
</pmlcore:Observation>
</pmlcore:Sensor>
7.6.3 Elemento Observation
Cada elemento Observation contem dados que são resultados de leituras de um sensor. Eles devem ser identificados com a data e hora da observação. Pode ter também um identificador e uma referência ao comando que foi emitido para realizar a observação.
O elemento de observação é constituído por:
o Um elemento ID opcional
o Um elemento Command Opcional
o Em elemento DateTime
o Zero ou vários elementos de dados (elemento data)
o Zero ou vários elementos Tag
Elemento DateTime: O elemento DateTime captura a hora e a data quando uma observação é feita. Utiliza da definição [XSD] “datetime”
Elemento Command: O elemento Command pode ser utilizado para especificar o comando que foi utilizado para acionar a observação. Se o comando fosse acionado em um leitor RFID, poderíamos ter como exemplo um comando “Leia as Tags”. A definição dos comandos possíveis está fora do escopo da PML Core.
Exemplo de codificação para um elemento
observation em XML:
<pmlcore: Sensor>
<pmluid:ID>urn:epc:1:4.16.36</pmluid:ID>
<pmlcore:Observation>
<pmluid:ID>00000001</pmluid:ID>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Command>READ_PALLET_TAGS_ONLY</pmlcore:Command>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.400</pmluid:ID>
</pmlcore:Tag>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.401</pmluid:ID>
</pmlcore:Tag>
</pmlcore:Observation>
</pmlcore:Sensor>
7.6.4 Elemento Data
O elemento Data deve ser usado para representar os dados quando um sensor faz uma leitura de uma propriedade ou entidade, a não ser que os dados capturados pelo sensor possam ser representados por um elemento tag. Pode ser usado para representar dados simples ou estruturados.
O elemento Data é constituído por:
o Elemento Text
o Elemento Binary
o
Elemento XML
Elemento Text: O Elemento Text deve ser utilizado para representar observações genéricas e notações em texto feitas pelos sensores ou informações que possam ser manipuladas neste formato, desde que os dados contidos na observação não contenham informações que devam ser representadas por outros elementos. Utiliza a definição [XSD] “string”.
Exemplo de codificação para um elemento
Text em XML:
<pmlcore:Sensor>
<pmluid:ID>urn:epc:1:124.162.37</pmluid:ID>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Data>
<pmlcore:Text>temp=22,24,25,22,22,23,22</pmlcore:Text>
</pmlcore:Data>
</pmlcore:Observation>
</pmlcore:Sensor>
Elemento Binary: O Elemento Binary deve ser utilizado para representar blocos de dados em hexadecimal. Similar ao elemento Text o elemento Binary deve ser usado para representar observações genéricas dos sensores, desde que os dados contidos na observação não contenham informações que devam ser representadas por outros elementos. . Utiliza a definição [XSD] “hexbinary”.
Exemplo de codificação para um elemento Binary em XML:
<pmlcore:Sensor>
<pmluid:ID>urn:epc:1:124.162.37</pmluid:ID>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Data>
<pmlcore:Binary>
0FB8A0F5CB0F11000FB8A0F5CB0F11000FB8A0F5CB0F1100</pmlcore:Binary>
</pmlcore:Data>
</pmlcore:Observation>
</pmlcore:Sensor>
Elemento XML: O elemento XML deve ser usado quando alguém desejar representar dados com elementos XML que não estão especificados na PML Core. Com este elemento, a PML Core torna possível que sejam inseridos tipos diferentes de dados que não foram previstos. Utiliza a definição [XSD] “any”.
Exemplo de codificação para um elemento XML em XML:
<pmlcore:Sensor>
<pmluid:ID>urn:epc:1:124.162.37</pmluid:ID>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Data>
<pmlcore:XML>
<TemperatureReading
xmlns="http://sensor.example.org/">
<Unit>Celsius</Unit>
<Value>5.3</Value>
</TemperatureReading>
</pmlcore:XML>
</pmlcore:Data>
</pmlcore:Observation>
</pmlcore:Sensor>
7.6.5 Elemento Tag
O elemento Tag é um tipo especial de valor observado que pode representar qualquer tipo de dispositivo que pode ser detectado por um sensor. Pode conter memória para armazenar dados e pode conter outros tipos de sensores como de temperatura e umidade. Embora tenha essas características, o elemento Tag não precisa ser um dispositivo eletrônico como um tag RFID. Por exemplo, um código de barras detectado por um leitor de código de barras pode ser considerado um Tag neste foco. Utiliza a definição [XSD] “tag”.
O elemento Tag é constituído por:
o Elemento ID
o Um elemento Data opcional
o Zero ou vários elementos Sensor
O elemento sensor contido no elemento Tag é usado para fornecer informações dos dados capturados pelos sensores montados em Tags. Isto reflete uma estrutura recursiva onde um sensor detecta um Tag que contém outros sensores.
Exemplo de codificação para um elemento Tag em XML:
<pmlcore:Sensor>
<pmluid:ID>urn:epc:1:4.16.36</pmluid:ID>
<pmlcore:Observation>
<pmluid:ID>00000001</pmluid:ID>
<pmlcore:DateTime>2002-11-06T13:
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.400</pmluid:ID>
<pmlcore:Sensor>
<pmluid:ID>urn:epc:1:12.8.128</pmluid:ID>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T11:
<pmlcore:Data>
<pmlcore:XML>
<TemperatureReading xmlns="http://sensor.example.org/">
<Unit>Celsius</Unit>
<Value>5.3</Value>
</TemperatureReading>
</pmlcore:XML>
</pmlcore:Data>
</pmlcore:Observation>
<pmlcore:Observation>
<pmlcore:DateTime>2002-11-06T12:
<pmlcore:Data>
<pmlcore:XML>
<TemperatureReading
xmlns="http://sensor.example.org/">
<Unit>Celsius</Unit>
<Value>5.8</Value>
</TemperatureReading>
</pmlcore:XML>
</pmlcore:Data>
</pmlcore:Observation>
</pmlcore:Sensor>
</pmlcore:Tag>
</pmlcore:Observation>
</pmlcore:Sensor>
7.7 Esquemas XML
7.7.1 PMLCore.xsd
<?xml version="1.0"
encoding="UTF-8"?>
<schema targetNamespace="urn:autoid:specification:interchange:PMLCore:xml:schema:1"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:autoid="http://www.autoidcenter.org/2003/xml"
xmlns:pmlcore="urn:autoid:specification:interchange:PMLCore:xml:schema:1"
xmlns:pmluid="urn:autoid:specification:universal:Identifier:xml:schema:1"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="1.0">
<import
namespace="urn:autoid:specification:universal:Identifier:xml:schema:1"
schemaLocation="../Universal/Identifier.xsd"/>
<annotation>
<documentation>
<autoid:program>Auto-ID
version 1.0</autoid:program>
<autoid:purpose>PML
Core Specification version 1.0</autoid:purpose>
</documentation>
</annotation>
<element
name="Sensor" type="pmlcore:SensorType"/>
<complexType
name="AnyXMLContentType">
<annotation>
<documentation>
<autoid:definition>The
AnyXMLContentType provides localized openess </autoid:definition>
</documentation>
</annotation>
<sequence>
<any
namespace="##any"
processContents="skip">
<annotation>
<documentation>
<autoid:definition>Any
content</autoid:definition>
</documentation>
</annotation>
</any>
</sequence>
</complexType>
<complexType
name="DataType">
<annotation>
<documentation>
<autoid:definition>The
Data element holds text, binary or XML data.</autoid:definition>
</documentation>
</annotation>
<choice>
<element
name="Text" type="string">
<annotation>
<documentation>
<autoid:definition>Text
value</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="Binary" type="hexBinary">
<annotation>
<documentation>
<autoid:definition>Binary
value</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="XML" type="pmlcore:AnyXMLContentType">
<annotation>
<documentation>
<autoid:definition>The
XML element holds any XML elements the instance author would
like to include. It is provided to enable localized
openness and to allow instance document authors to create
instance documents containing elements above and
beyond what is specified by the PML CORE
schema</autoid:definition>
</documentation>
</annotation>
</element>
</choice>
</complexType>
<complexType
name="ObservationType">
<annotation>
<documentation>
<autoid:definition>Information
related to an observation/measurement by a sensor in the EPC
Network. Observations represent measurements by the
sensor. They associate the actual observed data with the
sensor.</autoid:definition>
</documentation>
</annotation>
<sequence>
<element
ref="pmluid:ID"
minOccurs="0">
<annotation>
<documentation>
<autoid:definition>The
observation ID element is a number assigned to this specific
observation.</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="DateTime"
type="dateTime">
<annotation>
<documentation>
<autoid:definition>The
Observation DateTime element denotes the date and time stamp
when the observation was made.</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="Command" type="string"
minOccurs="0">
<annotation>
<documentation>
<autoid:definition>The
observation command element denotes the command was issued
to the sensor to trigger the observation.</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="Tag" type="pmlcore:TagType"
minOccurs="0"
maxOccurs="unbounded">
<annotation>
<documentation>
<autoid:definition>The
Observation Tag element denotes tags observed by a sensor as
part of the observation.</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="Data" type="pmlcore:DataType"
minOccurs="0"
maxOccurs="unbounded">
<annotation>
<documentation>
<autoid:definition>The
Observation Data element denotes any data captured by the
sensors as part of the observation.</autoid:definition>
</documentation>
</annotation>
</element>
</sequence>
</complexType>
<complexType
name="SensorType">
<annotation>
<documentation>
<autoid:definition>Information
related to a sensor in the EPC Network. A sensor is any device that
is capable of making measurements e.g. RFID readers,
temperature sensors, humidity sensors.</autoid:definition>
</documentation>
</annotation>
<sequence>
<element
ref="pmluid:ID">
<annotation>
<documentation>
<autoid:definition>The
Sensor ID element is the number assigned to this particular sensor
in the EPC network. It is by default an EPC. If a
different identification scheme is to be used, the identifiation
scheme must be specified using the attributes of the
identifier type.</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="Observation"
type="pmlcore:ObservationType"
maxOccurs="unbounded">
<annotation>
<documentation>
<autoid:definition>The
Sensor Observation element denotes observations/measurements
made by this particular sensor.</autoid:definition>
</documentation>
</annotation>
</element>
</sequence>
</complexType>
<complexType
name="TagType">
<annotation>
<documentation>
<autoid:definition>Information
related to a tag in the EPC Network. A tag is any electronic or nonelectronic
device that carries at least an identifier.</autoid:definition>
</documentation>
</annotation>
<sequence>
<element
ref="pmluid:ID">
<annotation>
<documentation>
<autoid:definition>The
Tag ID element is a unique number assigned to the
tag.</autoid:definition>
</documentation>
</annotation>
</element>
<element
name="Data" type="pmlcore:DataType"
minOccurs="0">
<annotation>
<documentation>
<autoid:definition>The
Tag Data element contains any data stored on the
tag.</autoid:definition>
</documentation>
</annotation>
</element>
<element
ref="pmlcore:Sensor"
minOccurs="0"
maxOccurs="unbounded">
<annotation>
<documentation>
<autoid:definition>The
Tag Sensor element denotes any sensor that is mounted on the
tag</autoid:definition>
</documentation>
</annotation>
</element>
</sequence>
</complexType>
</schema>
7.7.2
Identifier.xsd
<?xml version="1.0"
encoding="UTF-8"?>
<schema targetNamespace="urn:autoid:specification:universal:Identifier:xml:schema:1"
xmlns:pmluid="urn:autoid:specification:universal:Identifier:xml:schema:1"
xmlns:autoid="http://www.autoidcenter.org/2003/xml"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="1.0">
<annotation>
<documentation>
<documentation>
<autoid:program>Auto-ID
version 1.0</autoid:program>
<autoid:purpose>PML
Core Specification version 1.0</autoid:purpose>
</documentation>
</documentation>
</annotation>
<element
name="ID" type="pmluid:IdentifierType"/>
<annotation>
<documentation>
<autoid:definition>A
reusable element of type 'IdentifierType'</autoid:definition>
</documentation>
</annotation>
<complexType
name="IdentifierType">
<annotation>
<documentation>
<autoid:definition>A
character string to identify and distinguish uniquely, one instance of an
object
in an identification scheme from all other objects
within the same scheme</autoid:definition>
</documentation>
</annotation>
<simpleContent>
<extension base="token">
<attribute name="schemeID"
type="token" use="optional">
<annotation>
<documentation>
<autoid:definition>The
identifier of the identification scheme</autoid:definition>
</documentation>
</annotation>
</attribute>
<attribute name="schemeAgencyID"
type="token" use="optional">
<annotation>
<documentation>
<autoid:definition>The
identifier of the agency that maintains the identification
scheme</autoid:definition>
</documentation>
</annotation>
</attribute>
<attribute name="schemeVersionID"
type="token" use="optional">
<annotation>
<documentation>
<autoid:definition>The
version of the identification scheme</autoid:definition>
</documentation>
</annotation>
</attribute>
<attribute name="schemeURI"
type="anyURI" use="optional">
<annotation>
<documentation>
<autoid:definition>The
Uniform Resource Identifier that identifies where the
Identification Scheme is located</autoid:definition>
</documentation>
</annotation>
</attribute>
</extension>
</simpleContent>
</complexType>
</schema>
|
Capitulo 8 |
Object Name Service
(ONS) |
O Object Name Service(ONS) fornece um serviço de busca para traduzir um EPC em uma ou várias URLs(Uniform Resource Locator) onde maiores informações sobre o objeto podem ser encontradas.
O ONS pode fornecer serviços estáticos e dinâmicos, onde normalmente o ONS estático fornece URLs para informações mantidas pelos fabricantes dos objetos; e ONS dinâmico registra uma seqüência de como objetos se movem através de estoques, empresas, etc.
Cache do ONS(ONS Local Cache) - O ONS Local Cache é utilizado para reduzir a necessidade de consultas ao ONS Global de cada objeto visível à rede , já que valores recém-solicitados podem ser armazenados em um cache local , que funciona como um primeiro ponto de chamadas para as consultas ao ONS. O ONS local cache pode também gerenciar a procura de EPCs internos privados para rastreamento de ativos. Associado ao cache local estarão as funções de registro que registram EPCs junto ao ONS Global e com o sistema ONS dinâmico.
O ONS é desenvolvido utilizando a mesma tecnologia do DNS(Domain Name Service) para a Internet.
Figura 8.1: Exemplo da arquitetura de
redes EPC entre duas empresas com ONS
Fonte: EPCglobal
8.1 Conceitos gerais sobre o
ONS
A arquitetura proposta pelo Auto-Id fornece um método para a inclusão de produtos comerciais em sistemas que funcionam em rede. Está arquitetura faz uma série de suposições axiomáticas na qual a mais importante é que deve-se incentivar o uso das arquiteturas e dos padrões já existentes para a Internet.
Mesmo que um método de acesso a recursos de rede seja um mecanismo muito útil, ele apenas pode ser usado em uma rede onde mecanismos sejam fornecidos para realizar pesquisas sobre um objeto identificador. A combinação entre um identificador e um mecanismo de pesquisa cria um serviço dinâmico que pode ser usado para obtenção de metadados sobre qualquer objeto, sem haver a necessidade de grandes bases de dados que teriam que ser sincronizadas e que seriam conseqüentemente caras. Este processo é parte dos conceitos básicos de integração da auto identificação.
De acordo com a suposição que deve-se utilizar a arquitetura e os padrões já existentes na Internet o ONS utiliza o Sistema de Nomes de Domínio(DNS) para busca de informações e resolução dos códigos EPC, o que significa que o formato das consultas e respostas devem aderir aos padrões do DNS. Quando for realizada uma consulta o EPC será convertido para um resultado da forma “Nome-Dominio” e os resultados devem ser um registro valido no DNS.
Figura 8.2: Consulta típica em um ONS Fonte: EPCglobal
No exemplo da Figura 8.2 temos a seguinte seqüência de eventos que podem descrever o funcionamento do ONS:
1.Uma seqüência de bits contendo um EPC é lida a partir de uma tag RFID.
Ex: (01 000000000000000000010 00000000000011000 000000000000000110010000)
2.O Leitor que efetuou a leitura manda a seqüência de Bits para um Servidor local.
Ex: (01 000000000000000000010 00000000000011000 000000000000000110010000)
3.O Servidor local converte a seqüência de bits para um Formulário URI que segue as especificações do tag e envia o formulário para um servidor(resolver) dentro da arquitetura ONS.
Ex: urn:epc:1.2.24.400
4.O resolver converte o formulário URI para um nome de domínio e lança uma consulta DNS buscando os registros NAPTR(Naming Authority Pointer) para este domínio.
Ex: 24.2.1.onsroot.org
5.A infra-estrutura de DNS retorna uma série de repostas em forma de registros para o servidor ONS local que apontam para um ou mais serviços.
6.O servidor ONS local resolve os registros retornados pelo DNS e os converte para uma URL que aponta para o servidor PML que deverá ser contatado.
Ex: http://pml.example.com/
pml-wsdl.xml
7.O Servidor local então se comunica com o servidor PML que está indicado na URL.
8.2 EPC e Consultas ao ONS
O ONS que será especificado neste sub-capitulo terá um EPC como entrada. Será assumido que o EPC está no formulário URI: i.e. urn:epc:1.2.24.400 . Em geral este formulário é utilizado para todos componentes da arquitetura de auto-identificação alem dos leitores de tags.
É importante observar que na especificação do ONS versão 1.0 não são feitas consultas diretamente ao EPC. As consultas param no nível do produto, sendo que consultas para um dado numero de série deverão ser resolvidas através de consultas subseqüentes na camada dos servidores de aplicação designados pelos resultados das consultas ONS. A realização de consultas ONS no nível do numero de série assim como os impactos econômicos da adoção desta possibilidade é um assunto que ainda está em aberto nesta especificação e que deve ser discutido em versões posteriores a esta especificação.
8.2.1 Formato das Consultas DNS
Para consultar EPCs ao DNS, o formulário URI (i.e. urn:epc:1.2.24.400) deve ser convertido para um formulário do tipo “Nome-Dominio”. Neste processo geralmente ocorrem os seguintes passos:
1. O cabeçalho “urn:epc:” é removido, Ex: ( 1.2.24.400 )
2. O campo do numero de série é removido, Ex: ( 1.2.24 )
3. Inverte-se a ordem dos campos restantes, Ex: (24.2.1)
4. Incrementa-se “.onsroot.org” resultando em: (24.2.1.onsroot.org )
Então, uma aplicação DNS comercial pode ser usada para lançar uma consulta DNS do tipo código 35 (registros NAPTR). Por enquanto não há uma API que integre o ONS com o DNS, logo o método exato de consulta do ONS atualmente depende da biblioteca que está sendo utilizada no DNS. Quando existir uma API para o ONS os detalhes de como a consulta DNS é construída será ocultada dentro das aplicações.
8.2.2 Formato dos Resultados
Os resultados das consultas devem estar na forma de registros NAPTR. Atualmente servidores DNS retornam dados em diversos formatos não padronizados. Enquanto não existir uma API para DNS que padronize os dados de uma consulta, o método pelo qual os dados serão analisados dependerão da ferramenta DNS usada na implementação. Atualmente, o conteúdo dos registros DNS estão formatados logicamente como na tabela 8.1 a seguir:
|
Order |
Pref |
Sinalização |
Serviço |
RegExp |
Substituição |
|
0 |
0 |
U |
EPC+pml |
!^.*$!http://company.com/cgi-bin/pmlservice! |
.(ponto) |
Tabela 8.1: Formato de um registro
DNS Fonte:EPCglobal
O campo Order é usado para assegurar que os registros NAPTR estão representados na ordem correta, já que o DNS não garante a ordenação dos conjuntos de resultados. Se os registros em um conjunto são validos, a ordenação dos valores indica se os registros de um subconjunto podem ser considerados equivalentes. Se os registros são considerados equivalentes, a aplicação não terá que escolher o registro mais apropriado através da combinação dos campos Pref e Serviço(Service). Isto pode ser usado para conseguir um efeito de balanceamento de carga, entre dois ou mais registros. Por exemplo, se existem 4 registros e os três primeiros tem o campo Order com o valor ‘0’, enquanto o ultimo registro tem o campo Order com o valor ‘1’, os três primeiros campos são considerados equivalentes e usados para o balanceamento. Se os mesmos três registros tiverem os mesmos valores para os campos Pref e Serviço, então é possível escolher um registro aleatório entre os três. Se os valores dos campos Pref são diferentes, mas os campos Serviço são iguais, então os campos Pref são utilizados para definir a precedência entre quais registros serão utilizados, e que os registros com uma numeração mais baixa deverão ser processados antes dos que os registros de numeração mais alta.
O campo Serviço é importante neste processo porque a aplicação pode necessitar somente daqueles registros que contenham determinados serviços.
O campo de Sinalização(Flag) e preenchido com ‘u’ para indicar que o campo Regexp contem uma URI. O campo Serviço contem um indicador de qual tipo de serviço pode ser encontrado na URI. Este recurso permite ao ONS indicar múltiplas terminações para um serviço para diversas classes de serviços. O campo Substituição (Replacement) é um campo especial para serviços de DNS, mas não é utilizado na arquitetura de auto- identificação, e por isso será preenchido com apenas um ponto “.”.
Os serviços são particularmente importantes quando são utilizados para a criação de “classes” de servidores,sendo que estas classes são especificadas e registradas como autoridades. Elas podem ser usadas para a especificação desde serviços muito simples a serviços complexos.
No exemplo da tabela 8.1 o preenchimento do campo Serviço com o valor “EPC+pml” está sendo usado para diferenciar este registro de outros que possam existir; e especificamente a porção ‘pml’ é utilizada para designar a classe do serviço. Na tabela 8.2 serão descritos outros tipos de serviços possíveis.
O campo RegExp(expressão regular) é usado para especificar a URI para o serviço que está sendo descrito. A informação contida neste campo é uma extensão POSIX, significando que o primeiro caractere encontrado no campo se torna o delimitador entre a expressão regular e a parte que pode ser reescrita. Conforme o preenchimento do campo na tabela 8.1
O primeiro caractere encontrado é o “!”(delimitador) a porção da expressão regular é: ‘^.*$’ o que é igual a “encontre qualquer coisa” e a parte que pode ser reescrita é: 'http://company.com/cgi-bin/pmlservice' .
Em versões anteriores a esta especificação do ONS os resultados eram apenas endereços IP, mas isso é insuficiente devido a necessidade de utilização de protocolos como o SOAP que estão inseridos sobre o HTTP. Em quase todos s protocolos modernos é necessária a adição de nomes ou patches para informações, então o motivo do campo estar na forma de uma expressão regular é que o registro NAPTR é usado por outras aplicações que terão que reescrever a URI para incluir outras informações, embora este recurso não esteja sendo utilizado aqui. No futuro pode ser necessária a utilização das expressões regulares e também de funções de substituição sobre o campo RegExp.
8.3
Exemplos de Consultas
Os exemplos da tabela 8.2 descrevem uma consulta ao EPC “urn:epc:1.47400.11015.583865” , que representa o produto “Gillete Match 3 Descartável”. A aplicação de um cliente qualquer deseja obter informações sobre este produto, e então lança uma consulta através da infra-estrutura ONS e como resultado os seguintes registros seriam retornados:
|
Order |
Pref |
Sinalização |
Serviço |
RegExp |
Substituição |
|
0 |
0 |
u |
EPC+ws |
!^.*$!http://gillette.com/autoid/sensor3.wsdl! |
. |
|
0 |
0 |
u |
EPC+pml |
!^.*$!http://gillette.com/autoid/cgi-bin/pml.php! |
. |
|
0 |
0 |
u |
EPC+html |
!^.*$!http://www.gillette.com/products/grooming_men.asp! |
. |
|
0 |
0 |
u |
EPC+xmlrpc |
!^.*$!http://gateway1.xmlrpc.com/servlet/gillette.com! |
. |
|
0 |
1 |
u |
EPC+xmlrpc |
!^.*$!http://gateway2.xmlrpc.com/servlet/gillette.com! |
. |
Tabela 8.2 Exemplos de registros retornados por
uma consulta ONS Fonte:
EPCglobal
8.3.1 Encontrando um arquivo WSDL
para um produto
Um exemplo muito simples mas muito importante é de uma aplicação ERP habilitada a trabalhar com serviços WEB(WEB Services). Esta aplicação seria capaz de aprender sobre novos produtos fazendo diversas chamadas a aplicações publicas disponibilizadas pelos fabricantes. Neste caso a aplicação pode simplesmente usar o ONS para ‘ver’ se existe um arquivo WSDL que descreve o que foi pedido através do Serviço WEB. A aplicação emite a consulta e recebe os registros, ela então interage com os registros procurando pelo serviço ‘ws’ que ira designar um arquivo WSDL que define o WEB Services disponível. Neste exemplo a localização é feita no primeiro registro e então a URI encontrada no campo RegExp é retornada.
8.3.2 Encontrando um Servidor PML
para um produto
Este exemplo mostra como um EPC pode ser utilizado para encontrar documentos PML sobre um produto. A informação pode estar dentro do vocabulário PML Core ou em outros vocabulários definidos pelo EPCglobal. Neste exemplo a informação seria encontrada no segundo registro e a URI seria extraída do campo RegExp.
8.3.3 Encontrando uma pagina HTML que contenha
informações sobre o produto
Este exemplo mostra como um serviço simples e de desenvolvimento rápido pode ser utilizado para encontrar informações sobre um produto apenas utilizando um Servidor WEB que contenha informações sobre um determinado produto. No terceiro registro da tabela 8.2 poderia ser disponibilizado informações sobre o produto sem que fosse necessária modificações nos sistemas existentes. As aplicações que fossem compatíveis com este serviço poderiam usar até mesmo navegadores para Internet disponíveis para exibir o conteúdo dessas informações.
8.3 .4 Encontrando um gateway
XML-RPC para interfaces WEB
Em alguns casos as empresas podem optar disponibilizar pessoalmente determinados serviços. Alguns serviços podem ser fornecidos por terceiros e no exemplo da tabela 8.2 não é fornecido um serviço XML-RPC próprio, ao invés disso é criado um gateway XML-RPC para SOAP que vai ser executado em um terceiro. Isto melhora a interoperabilidade simplificando as entradas no ONS e permitindo a utilização de novas aplicações com pequeno esforço. No exemplo da tabela 8.2 existem também dois registros que contem o mesmo valor no campo Order, isto significa que o campo Pref será usado para indicar a preferência sobre ouros registros, e se por alguma razão o registro que contem o campo Pref com o valor ‘0’ falhar, o registro outro registro que contem o campo Pref com o valor 1 poderá ser utilizado(balanceamento de carga ).
|
Capitulo 9 |
Projeto de
Implementação de Redes EPC |
Neste capítulo será proposta uma implementação que utilizará os componentes e elementos de hardware e software descritos durante este trabalho referentes às tecnologias RFID e EPC. Neste ambiente proposto, as duas tecnologias irão se interagir, de forma a termos configurada e implementada uma Rede EPC.
Na realidade, essa implementação proposta abrange dois ambientes: uma empresa fabricante (fornecedor) e um supermercado(cliente). Desta forma , essa Rede EPC é composta por esses dois elementos distintos(fornecedor / cliente) , que podem interagir entre si; para isso compartilhando recursos tanto da Infra-Estrutura EPC quanto da Infra-Estrutura necessária para troca de dados entre si (redes WAN, VPNs, etc).
Nessa implementação, o fornecedor é um laticínio que fornece leite à um supermercado. O leite é do tipo longa vida , envasado em caixas de 1 litro e colocados à venda em gôndolas específicas no supermercado.
A partir desse momento, iremos detalhar o funcionamento dos componentes e elementos que integram essa solução, tanto no fornecedor quanto no supermercado:
- Uma aplicação interna do Laticínio gera números de série baseados nos critérios de produção da empresa e os atribui aos registros de produtos existentes no seu Banco de Dados. A partir desse momento, cada caixa de leite a ser produzida já tem o seu número serial reservado.Uma segunda aplicação exporta os números de série gravados no Banco de Dados. A partir daí, os diversos EPCs são gerados através da concatenação do número serial com outros dados pertinentes à codificação. A partir desse momento, tem-se um segundo Banco de Dados, que podemos chamar de
Base de Dados EPC. Os EPCs são então fisicamente gravados nos tags que serão acoplados às caixas.
A codificação EPC utilizada nessa implementação é a GID-96. Conforme descrito no capítulo 5, essa codificação é composta de quatro campos: Header , Número Geral Diretor, Classe de Objeto e Número de Série.
Figura 9.1: Codificação GID-96 utilizada pelo Laticínio
- Durante o processo de envasamento , os tags RFID são acoplados às caixas, mais
especificamente nas abas laterais, pois é a área mais externa da caixa e que está mais distante do líquido contido. Quando acoplados, os tags já estão codificados com seus respectivos EPCs. Abaixo segue uma tabela que especifica as características dos tags utilizados nessa implementação:
|
Classe |
Memória |
Fonte de Energia |
Freqüência |
Custo |
|
1 |
WORM |
Passivo |
UHF (902 – 928 MHz / Região: Américas) |
US$ 0,02 |
Tabela 9.1: Especificações do tag
utilizado
A figura 9.2, ilustra o momento em que os tags são acoplados às caixas durante o processo de produção:
Figura 9.2:
Tags sendo acoplados às caixas
durante processo de produção
- Após passarem pela linha de produção, as caixas de leite deixam o Laticínio, tendo
como destino o Supermercado. Porém, antes de efetivamente entrarem no caminhão que realizará a distribuição, os tags passivos acoplados às caixas são ativados por um leitor RFID posicionado estrategicamente na saída do Laticínio. Assim que ativado, o tag envia ao leitor seu respectivo EPC. O leitor funcionará de modo a ler cada tag uma única vez, garantindo que todos os EPCs sejam lidos, porém sem que haja duplicidades em leituras. Nesse momento, a Base de Dados da empresa é alimentada com os registros de saída dos produtos que deixaram a empresa tendo como destino o Supermercado.
O leitor RFID é conectado à rede (LAN) da empresa através de uma conexão no padrão Ethernet 802.3. Os protocolos de rede utilizados pelo leitor são os protocolos TCP/IP.
|
Quantidade de Antenas |
Conexão de Rede |
Protocolos de Rede |
Freqüência |
Padrão |
|
4 |
Ethernet 802.3 |
TCP / IP |
UHF (902 – 928 MHz / Região: Américas) |
Interface Aérea: ISO 18000 – Parte 6 |
Tabela 9.2: Especificações do leitor
utilizado
A figura 9.3, ilustra o momento em que os tags são ativados pelo leitor RFID ao deixarem o Laticínio, para que em seguida sejam levados ao Supermercado:
Figura 9.3: Leitura dos EPCs codificados nos tags realizada pelo leitor RFID
- Quando a carga chega ao Supermercado, o leitor RFID que está posicionado na entrada do estoque realiza a leitura dos tags dos produtos. Assim que ativados, os tags enviam ao leitor seus respectivos EPCs.
Figura 9.4:
Entrada dos produtos no estoque do Supermercado
- A partir do momento da leitura dos tags, ocorrem os seguintes passos:
- Assim como no Laticínio, o leitor RFID do estoque do Supermercado está conectado à rede LAN no padrão Ethernet 802.3, utilizando os protocolos TCP/IP. Assim, ao receber o EPC, o leitor o repassa ao Servidor Savant através da rede LAN do Supermercado.
- Neste momento, o Módulo de Processamento do Savant autoid.readerproxy é acionado através do evento de leitura. Paralelamente, o Servidor de Aplicações do Supermercado emite continuamente comandos ao Savant através de APIs. Esses comandos são invocados a partir da utilização da MTB XML / RPC sobre HTTP. O comando emitido pelo Servidor de Aplicações é o RunCommand , que tem como parâmetros o Método GetTagList e o código do leitor específico. O retorno deste comando nada mais é que o conteúdo EPC de todos os tags lidos pelo leitor no seu raio de alcance no exato momento em que ele recebe a solicitação de leitura pelo Savant.Desta forma, o Servidor de Aplicações receberá todos os EPCs , que estarão no formato binário.Como a codificação utilizada pelo Laticínio é o GID-96 , esse conteúdo será um código binário de 96 bits.
|
Módulo de Processamento Utilizado |
MTB Utilizada |
Comando Executado |
Parâmetro 1 |
Parâmetro 2 |
Retorno do Comando |
|
autoid.readerproxy |
XML-RPC sobre HTTP |
RunCommand |
GetTagList |
Código do
Leitor |
Lista contendo os EPCs lidos |
Tabela 9.3:
Módulo de Processamento e MTB utilizados pelo Savant
- O Servidor de Aplicações converte o código binário de 96 bits em uma representação URI., que é então enviada ao Servidor Local ONS. Conforme descrito no Capítulo 8, o resolver do Servidor Local ONS converte o formulário URI para um nome de domínio e lança uma consulta DNS buscando os registros NAPTR para esse domínio. O ONS Local (Cache) verifica se já existem registros para esse produto. Neste caso, não há registros no Cache ONS referentes aos produtos recebidos pelo Supermercado , já que é a primeira compra que o ele faz com o Laticínio.
- A consulta é então encaminhada para a Infra-Estrutura DNS / ONS , para que seja feita uma pesquisa global. Após encontradas as informações mantidas na Infra-Estrutura do Laticínio, os registros encontrados são retornados ao ONS do Supermercado, que disponibiliza os resultados ao Servidor de Aplicações e ao mesmo tempo armazena os resultados em seu Cache.
|
Order |
Pref |
Sinalização |
Serviço |
RegExp |
Substituição |
|
0 |
0 |
U |
EPC+ws |
!^.*$!http://laticinio.com.br/autoid/leiteuht.wsdl! |
. |
|
0 |
0 |
U |
EPC+pml |
!^.*$!http:// laticinio.com.br /autoid/cgi-bin/pml.php! |
. |
|
0 |
0 |
U |
EPC+html |
!^.*$!http:// laticinio.com.br/produtos/leiteuht.asp! |
. |
|
0 |
0 |
U |
EPC+xmlrpc |
!^.*$!http://gateway1.xmlrpc.com/servlet/laticinio.com.br! |
. |
Tabela 9.4:
Registros
retornados pela consulta ao ONS do Laticínio
-Para a aplicação do Supermercado, as únicas informações necessárias são as que estão no servidor PML do Laticínio. Então, o único registro utilizado pelo Servidor de Aplicações é o registro que traz informações sobre o serviço ‘EPC+pml’. Por isso, o segundo registro da tabela de resultados é selecionado pela aplicação, ou seja, a aplicação irá utilizar o conteúdo do campo RegExp que contem a URL para o servidor PML indicado na consulta:
http://
laticinio.com.br /autoid/cgi-bin/pml.php
- O Servidor de Aplicações cantata o servidor PML do Laticínio indicado na URL através de uma rede WAN que interliga os dois estabelecimentos e requisita ao servidor PML as informações referentes aos EPCs lidos. O servidor PML acessa as bases de dados do Laticínio que contém as informações dos produtos, e as retorna para o Servidor de Aplicações do Supermercado. As informações retornadas pelo servidor PML podem ser por exemplo a Data de fabricação, Lote, Data de validade e etc...
-As bases de dados do Supermercado são alimentadas com as informações retornadas pelo servidor PML.
Figura 9.5: Arquitetura da rede EPC
interligando as duas empresas
6 Agora os produtos são encaminhados para as gôndolas do Supermercado onde serão disponibilizados para os consumidores.
Nas gôndolas também serão instalados leitores RFID que estarão interligados a rede EPC existente no Supermercado. O Servidor de Aplicações periodicamente irá disparar uma requisição para a realização de uma contagem de quantos EPCs existem na gôndola, indicando quantas caixas do produto ainda restam para venda. No servidor de aplicações será configurado um limite mínimo para a quantidade do produto em oferta nas gôndolas. Se, durante a contagem for verificado que o limite mínimo foi atingido, o Servidor de Aplicações emitirá uma requisição para que mais produtos sejam levados até as gôndolas.
Figura 9.6: Leitor RFID instalado em
gôndola para controle de reposição
|
Conclusões |
|
Após o estudo das características, propriedades e implementações da tecnologia RFID e das Redes EPC, foi possível concluir que a adoção de um ambiente que as utilize pode trazer muitos benefícios; mas que em contra-partida podem causar um esforço muito alto de implementação ou de migração, caso seja esta a situação.
Quanto à tecnologia RFID, apesar de atualmente ainda apresentar um alto potencial de aumento de utilização e mesmo de evolução técnica, é possível constatar que sua implementação já é hoje largamente utilizada em algumas aplicações, como por exemplo pedágios e estacionamentos eletrônicos, controle de acesso e identificação de animais. Com a evolução das telecomunicações, tanto no aspecto referente ao hardware quanto às aplicações associadas, a adoção da tecnologia RFID tornou-se mais barata, eficiente e acessível. A partir desse fator, foi possível aplicar nesta tecnologia , por exemplo, a utilização de tags passivos e antenas acopladas de tamanhos muito pequenos, possibilitando, desta forma , uma alta portabilidade nas aplicações.
Por isso, a escolha do uso da tecnologia RFID nas Redes EPC acabou por acontecer, já que a proposta dessas Redes é exatamente que sejam largamente utilizadas comercialmente. Outro fator colaborador foi a definição de protocolos e normas referentes ao RFID, o que facilita a integração e a organização de projetos e implementações.
A partir do momento que a tecnologia RFID está no contexto de utilização das Redes EPC, outro desafio surgido foi a definição da infra-estrutura de software e interconexão requeridas para a sua utilização consistente, eficiente e padronizada. Antes mesmo do software a ser utilizado, foi necessário definir as possíveis codificações que o código EPC pode assumir fisicamente em um tag. Para tal, a organização EAN.UCC definiu em conjunto com o organização Auto-ID Center (atual EPCglobal) diversas codificações, algumas baseadas no atual código de barras, e outras novas, especificamente criadas para usufruir da nova proposta EPC. A criação de novas codificações, como por exemplo às de identificação de bens e ativos, dão maior flexibilidade de implementação e utilização à tecnologia.
Os elementos de software, interconexão e integração propostos pelo EPCglobal também propõem facilidade, agilidade e implementação das Redes, além de tentarem diminuir os custos e esforços de migração de sistemas equivalentes para empresas que querem passar a adotar o padrão. A utilização, por exemplo, de padrões baseados em XML (PML), infra-estrutura DNS / Internet (ONS) e hardwares compatíveis com protocolos TCP / IP tendem a dar maior agilidade e facilidade nas implementações , ao mesmo tempo que as empresas que estejam no processo de adoção do ambiente podem inclusive compartilhar recursos já existentes. Esses recursos podem inclusive ser de mão-de-obra, já que profissionais que tenham conhecimento em XML ou DNS / Internet, por exemplo, terão maior facilidade em ativar e gerenciar elementos da Rede EPC. Em relação às aplicações de software em si, o componente Savant (middleware do sistema), também proposto pela EPCglobal , é projetado a partir de interfaces que disponibilizam acesso de forma similar à componentes de linguagens orientadas a objetos, que são largamente utilizadas atualmente. Além disso, os módulos de processamento do Savant são projetados de forma a abstrair ao máximo o seu acesso a partir de linguagens de programação , ou seja , não define quais linguagens específicas devem ser utilizadas, deixando a cargo do implementador qual será a escolhida. Além disso, é possível criar novos módulos de processamento, fazendo com que o implementador possa customizar módulos de finalidades específicas para suas aplicações. E, além dos aspectos referentes aos módulos, o Savant disponibiliza canais de transporte de mensagens (MTBs) que são baseados em padrões comumente utilizados atualmente , como XML-RPC e SOAP-RPC.
Todos esses aspectos referentes à infra-estrutura citados acima (XML / PML, DNS / ONS e Savant) surgem como vantagens e benefícios da implementação das Redes, porém isso não significa que uma implementação ou migração seja uma tarefa fácil. Dependendo da aplicação , a complexidade de implementação pode ser alta, principalmente no aspecto referente à integração com sistemas já existentes em uma empresa.
Entretanto, outros aspectos referentes à adoção são importantes. O custo estimado para ativar e manter sistemas deste tipo ainda são muito altos e até mesmo difíceis de estimar em alguns casos , já que alguns componentes da solução ainda estão em fase final de projeto. De qualquer forma, o custo que mais dificulta a implementação é o referente aos próprios tags RFID. O mercado estima que o preço viável para que as Redes sejam largamente utilizadas é o de US$ 0,02 , porém ainda é muito difícil para os fornecedores de tags chegar a esse valor , a não ser em casos de compra em larga escala.
Outro aspecto da adoção é referente a privacidade , já que o conceito das Redes EPC possibilita o rastreamento completo de um determinado item. Essa questão ainda está sendo discutida e, tratando-se de um aspecto delicado, provavelmente ainda continuará sendo até que limites sejam estabelecidos.
De qualquer forma, a utilização da tecnologia é promissora, tanto no varejo (supermercados) quanto em logística. Porém , apesar de ter um apelo maior nesse segmentos, outros tipos de empresa podem usufruir desta tecnologia, já que será possível também automatizar e dar maior eficiência em identificação de bens e ativos de uma companhia qualquer.
No caso da logística e do varejo , estima-se que a curto prazo (entre 6 e 18 meses) a tecnologia esteja bem difundida em aplicações de rastreamento e de itens robustos de logística como containers, por exemplo. Á médio prazo (entre 2 e 3 anos) estima-se que já haja grande utilização em itens menores de logística (pallets , caixas) e também em itens(produtos) de venda, sendo estes provavelmente produtos pilotos, ou seja, produtos de grande apelo ao público. À longo prazo (entre 5 e 10 anos) estima-se que a tecnologia esteja finalmente difundida na área de logística e do varejo , sendo que todos os produtos (itens) de um supermercado , por exemplo, esteja equipado com tags de auto-identificação. Estima-se também , que nesse estágio exista um alto grau de integração entre as empresas, facilitando as transações sistêmicas e comerciais envolvidas.
Entretanto, é possível que mesmo antes dos prazos citados acima já exista uma grande utilização das Redes EPC, sendo que , por exemplo, grandes redes de supermercado já estão começando a pressionar seus fornecedores para adequarem seus produtos dentro deste novo conceito.
Após o estudo das Redes EPC, concluiu-se que , apesar de diversas empresas e entidades estarem concentrando esforços para tornar a tecnologia uma realidade , ainda será necessário muito empenho , estudo e análise por parte tanto das empresas que queiram adotar a solução , quanto da organização idealizadora do conceito (EPCglobal). Durante o processo de pesquisa do trabalho houve inclusive uma relativa dificuldade na compreensão das especificações oficiais da organização , já elas são muito recentes e ainda passam por um processo de aprimoramento.
De qualquer maneira, como todo grande projeto proposto , as Redes EPC deverão mobilizar esforços continuamente , mesmo após sua utilização ser difundida. O que importa, acima de tudo , é que sua adoção traga benefícios reais e úteis à sociedade, assim como toda nova tecnologia proposta deve fazer.
|
Bibliografia |
|
LANDT , Jeremy ; Shrouds of Time ; Artigo
publicao por AIM Inc. ; Pittsburgh ; 2001
HODGES , Steve e
HARRISON , Mark ; Demystifying RFID : Principles & Praticalities ; Artigo Publicado por Auto-Id Center ; Massachusetts ; 2003
SARMA , Sanjay E. e ENGELS , Daniel W. ; On The
Future os RFID Tags and Protocols ; Artigo
publicado por Auto-Id Center ; Massachusetts ; 2003
LEWIS , Steve ; A Basic Introduction to RFID
Technology and its use in the supply chain ; Artigo publicado por Laran RFID ; 2004
REHLING , Steve ; EPC Tag Data Specification 1.1 Rev 1.24 ; Especificação Técnica publicada por EPCglobal ; Massachusetts ; 2004
CLARK , Sean , TRAUB , Ken , ANARKAT , Dipan e OSINSKI , Ted ; WD-Savant-1.0- Especificação Técnica publicada por EPCglobal ; Massachusetts ; 2003
HARRISON , Mark , OSINSKI , Ted , ANARKAT , Dipan e FLOERKEMEIER , Chrstian PML Core Especification v1.0 ; Especificação Técnica publicada por EPCglobal ; Massachusetts ; 2003
FOLEY , Joe , SARMA , Sanjay , SIU , Sunny e MEALLING , Michael ; Auto-ID Object Name Service(ONS) 1.0 ; Especificação Técnica publicada por EPCglobal ;Massachusetts; 2003