rastreabilidade de bens em redes federadas - rfrbnet · rastreabilidade a um conjunto alargado de...
TRANSCRIPT
Rastreabilidade de bens em redes federadas - rfrbNet
Carlos Miguel da Costa Perdigao
Dissertacao para obtencao do Grau de Mestre emEngenharia Informatica e de Computadores
Juri
Presidente: Prof. Mario Rui Fonseca dos Santos GomesOrientador: Prof. Jose Manuel da Costa Alves MarquesVogal: Prof. Luis Manuel Antunes Veiga
Engo. Mario Duarte Alves de Sousa Romano
Outubro de 2010
Agradecimentos
Manifesto o meu agradecimento ao Professor Doutor Jose Alves Marques, pela sua orientacao durante
a realizacao deste trabalho. Agradeco igualmente ao Professor Miguel Pardal por toda a motivacao e
entusiasmo que transmitiu desde o primeiro dia e ainda por todo o esforco que realizou no acompanha-
mento deste estudo.
Agradeco tambem a Link Consulting, e em especial ao Eng. Mario Romano, por toda a ajuda
prestada atraves de apoio tecnico e observacoes sempre construtivas atraves da partilha da sua vasta
experiencia.
Quero agradecer a todos os meus familiares que sempre me apoiaram e motivaram ao longo de
mais uma etapa na minha vida tendo sido sempre um exemplo a seguir.
A todos os meus amigos que estiveram sempre presentes e me animaram nas fases mais crıticas
deste trabalho.
Finalmente o meu eterno agradecimento a minha namorada, por toda a compreensao, incentivo e
apoio que demonstrou tendo sido um verdadeiro braco direito ao longo deste ultimo ano.
A todos, o mais sincero agradecimento.
Lisboa, 22 de Novembro de 2011
Carlos Miguel da Costa Perdigao
Resumo
Este documento apresenta o problema da rastreabilidade de objectos, porque e tao importante e o estado
de arte de solucoes actuais que utilizam tecnologias RFID.
O objectivo principal e apresentar uma solucao para execucao de perguntas de rastreabilidade no
contexto de uma federacao, onde a participacao de uma organizacao varia ao longo do tempo.
Secundariamente foi definido um conjunto de polıticas que a federacao devera disponibilizar, de
forma a agilizar o seu comportamento e adaptar-se a mutacoes dentro da rede.
O estudo base deste trabalho e a framework e os standards EPCglobal, que definem entre outros
aspectos a estrutura da informacao, as interfaces de comunicacao, convencoes de nomes e algumas
consultas. Tambem foi levado em consideracao as solucoes actuais, cujos pontos fracos identificados, se
pretendem superar.
O trabalho desenvolvido sera validado atraves da execucao de pesquisas num ambiente controlado,
onde sera simulada a existencia de uma rede de rastreabilidade.
Abstract
This document presents the problem of object track and trace. Why is it so important and the state of the
art of current RFID based solutions. The main objective is to present a solution that allows the execution
of track and trace questions in a federation where ones participation mutates along time.
Secondly a set of policies were defined for use inside federation to agilize their behaviour in order
to fasten the adaptation to changes in business processes.
This work is based on EPCGlobal’s standards and framework, that define the structure of informa-
tion, interfaces and naming conventions. Present solutions were also taken into consideration whose
downsides this works final solution must overcome.
The solution will be validated throught practical results that will be mapped against the European
Union recommendations to track and trace systems.
Palavras Chave
Keywords
Palavras Chave
Rastreabilidade de produtos
Federacoes de entidades
Redes dinamicas
Polıticas de partilha de informacao
Arquitectura de sistemas RFID
Simulacao de redes de distribuicao
Keywords
Product track and trace
Entity network federations
Dynamic networks
Information sharing policies
RFID systems’ architecture
Supply chain simulation
�Indice
1 Introducao 1
1.1 Rastreabilidade AS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Rastreabilidade via Pedigree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Rastreabilidade via Redes proprietarias . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Rastreabilidade To Be . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Enquadramento 9
2.1 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Sistemas RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Etiquetas RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Leitores RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Sistemas de Informacao RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 EPCglobal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 EPCIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 ONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4 Discovery Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Rede Federada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Rastreabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i
2.5.3 Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 rfrbNet -Rede Federada de Rastreabilidade de Bens . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Arquitectura 25
3.1 Rastreabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Nıvel Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1.1 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Nıvel Logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.2.1 Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2.1.1 Bill-of-materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2.1.2 Track e Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.3 Nıvel tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3.1 EPCIS + ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.3.2 EPCIS + Discovery Services . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.3.3 Comparacao Arquitecturas . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Polıticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Identificacao e autorizacao de entidades . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2 Polıticas de partilha de informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Implementacao 49
4.1 Emulador de sistemas rfid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Federacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Repositorio EPCIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.2 Filtro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.3 Aplicacao Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.4 Discovery Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.5 Servidor Polıticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
ii
4.2.6 Servico Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Avaliacao 59
5.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Permitir a partilha de informacao entre parceiros . . . . . . . . . . . . . . . . . . . 59
5.1.2 O fluxo de mensagens simular o fluxo do produto na cadeia de fornecimento . . . 59
5.1.3 Mitigar utilizacoes abusivas do sistema . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.4 Permitir definir diferentes nıveis de pesquisa . . . . . . . . . . . . . . . . . . . . . . 61
5.1.5 Replicar alteracoes nas cadeias, em alteracoes nos acessos aos dados . . . . . . . . 61
5.1.6 Aceder informacao nos sistemas de cada entidade em vez de copias locais . . . . . 61
5.1.7 Suportar uma linguagem de negocio para definir permissoes de acesso e diferentes
nıveis de detalhe na informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.8 Capacidade de processar grandes quantidades de dados . . . . . . . . . . . . . . . 62
5.1.9 Uniformizar a informacao dos diversos sistemas . . . . . . . . . . . . . . . . . . . . 62
5.1.10 Definir primitivas para perguntas de rastreabilidade . . . . . . . . . . . . . . . . . 62
5.1.11 Definir algoritmos de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.12 Definir sistemas de autenticacao e autorizacao . . . . . . . . . . . . . . . . . . . . . 62
5.1.13 Garantir a escalabilidade do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.14 Manter-se operacional mesmo que existam falhas num dos elementos . . . . . . . 63
5.1.15 Definir e alterar permissoes de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Conclusoes 65
6.1 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Appendices 73
.1 Exemplo Polıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
iii
iv
Lista de Figuras
1.1 As 25 principais rotas logısticas aereas e marıtimas mundiais . . . . . . . . . . . . . . . . 2
1.2 Uma cadeia de fornecimento com registos pedigree e respectivo crescimento da informacao 4
1.3 Uma cadeia de fornecimento com informacao centralizada . . . . . . . . . . . . . . . . . . 5
1.4 Sistema de rastreabilidade proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Um sistema RFID tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Framework EPCGlobal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Estrutura do EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Diagrama da rede de distribuicao do cenario criado para fins de teste . . . . . . . . . . . . 22
3.1 Entidades no nıvel conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Processo de identificacao de objectos e obtencao dos eventos associados . . . . . . . . . . 29
3.3 Diagrama de eventos considerados para a realizacao de um BOM . . . . . . . . . . . . . . 30
3.4 Esquema conceptual do algoritmo generico para resolucao de BOMs . . . . . . . . . . . . 31
3.5 Diagrama de eventos considerados para a realizacao de um Trace . . . . . . . . . . . . . . 32
3.6 Esquema conceptual do algoritmo generico para resolucao de Traces . . . . . . . . . . . . 33
3.7 Arquitectura EPCIS + ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 Arquitectura EPCIS + Discovery Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 Exemplo de concorrencia nas redes de distribuicao . . . . . . . . . . . . . . . . . . . . . . . 41
3.10 Simplificacao obtida nas redes de distribuicao pela utilizacao de grupos . . . . . . . . . . 43
3.11 Simplificacao obtida nas redes de distribuicao pela utilizacao de roles . . . . . . . . . . . . 44
3.12 Processo de acordo de polıticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.13 Aplicacao das polıticas aos resultados das pesquisas . . . . . . . . . . . . . . . . . . . . . . 47
v
3.14 Arquitectura final da federacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1 Arquitectura logica do simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Arquitectura fısica do simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Tecnologias utilizadas na implementacao dos diversos modulos . . . . . . . . . . . . . . . 54
vi
Lista de Tabelas
2.1 Categorias de antenas e comparacao relativa das respectivas caracterısticas [9] . . . . . . . 11
2.2 Classes de etiquetas (EPCglobal 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 As quatro perguntas que o EPCIS pretende responder . . . . . . . . . . . . . . . . . . . . . 15
2.4 Eventos EPCIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Metodos definidos no nıvel logico com respectivos argumentos, retornos e descricao . . . 29
3.2 Metodos definidos no nıvel logico com respectivos argumentos, retornos e descricao . . . 32
3.3 Mapeamento dos metodos de resolucao de Trace com os metodos definidos no nıvel logico 34
3.4 Mapeamento dos atributos do evento conceptual com os atributos dos eventos EPCIS . . 35
3.5 Comparacao das arquitecturas apresentadas segundo os objectivos definidos inicialmente 39
3.6 Resultados obtidos pela aplicacao dos diversos nıveis de detalhe . . . . . . . . . . . . . . 46
4.1 Operacoes definidas para interagir com o simulador . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Descricao de cada componente do simulador . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1 Requisitos funcionais cumpridos por cada modulo da arquitectura final . . . . . . . . . . 60
vii
viii
1Introdu�c~aoO mundo como o conhecemos esta a mudar rapidamente, tornando-se mais global que nunca. A aber-
tura de fronteiras, a agilizacao dos meios de transporte, o comercio a escala global e a competicao entre
economias sao alguns dos factores que para tal contribuem. A imprevisibilidade dos mercados leva
muitas organizacoes a abandonar os modelos anteriores de producao Make-to-Forecast (MTF) para mo-
delos Make-to-Order (MTO onde a producao em massa e substituıda por producao on demmand [1]. Estas
mudancas comecam a ter impactos nas organizacoes que necessitam de optimizar e agilizar todos os
seus processos. A informacao que estas possuem e produzem sobre os seus produtos deixou de ser
exclusiva e a colaboracao entre parceiros uma obrigacao. A partilha de informacao entre os diversos
intervenientes e cada vez mais uma necessidade, sendo a base para os processos de optimizacao das ca-
deias de fornecimento. A agravar este facto, estao a surgir leis, cada vez mais restritas sobre a circulacao
de bens, que exigem um controlo rigoroso, em tempo real do percurso realizado por um determinado
produto. Estas leis estao neste momento focadas em nichos, altamente controlados, e sobre os quais in-
tervem um numero reduzido de entidades, levando a antever uma rapida expansao para ambitos mais
alargados.
Na uniao europeia actualmente, existe uma obrigacao na rastreabilidade da circulacao de medica-
mentos e de produtos considerados perigosos. O controlo da qualidade e cada vez mais rigoroso quando
se trata de bens alimentares e outros bens perecıveis. Esta progressao leva a antever uma expansao desta
rastreabilidade a um conjunto alargado de produtos e bens. As directivas actuais obrigam a uma clara
descricao dos sistemas de rastreabilidade usados para controlar a distribuicao dos produtos. No caso
dos medicamentos, e da responsabilidade do proprietario a “descricao do sistema de rastreabilidade
(...) para garantir que os produtos individuais e as suas materias-primas(...), possam ser rastreadas
pela origem, manufactura, empacotamento, armazenamento, transporte e entrega no hospital, clınica
ou intituicao onde o produto sera utilizado” [3].
Por outras palavras, o proprietario do medicamento, tem a responsabilidade de manter a rastrea-
bilidade dos medicamentos, e suas materias primas, durante todo o ciclo de vida do medicamento, ate
chegar ao consumidor final. Em 2008 em Portugal foram transportadas cerca de 333 milhoes de tonela-
das de produtos [4] o que demonstra a dimensao que um sistema deste podera tomar, impossibilitando
um controlo manual de cada produto.
Figura 1.1: As 25 principais rotas logısticas aereas e marıtimas mundiais[2]
De forma a cumprir esta directiva, a informacao respeitante a cada produto tem que ser partilhada
entre organizacoes e regras tem que ser estabelecidas. A realidade e que este controlo comecou com
os medicamentos, ja progrediu para alimentos geneticamente modificados [5] , armamento e municoes
para uso civil [6] e e expectavel que num futuro proximo seja obrigatorio em todos os produtos dentro
da Uniao Europeia.
Actualmente ao ser detectado um problema num lote obriga a que todos os produtos desse lote
sejam recolhidos. Como e possıvel a um produtor identificar em tempo util, todos os bens que poderao
estar improprios para consumo, estejam estes num estado puro ou transformado?
Este desafio justifica o aparecimento de novas tecnologias que possam resolver o problema da ras-
treabilidade de produtos. As tecnologias actuais, embora sejam estaveis e baseadas em standards, estao
focadas para uma utilizacao interna da organizacao, levantando novos problemas numa utilizacao en-
tre diversas entidades. Este foco dos sistemas actuais, contrasta com o objectivo final dos sistemas de
rastreabilidade, que e controlar um objecto durante toda a sua existencia.
Sabe-se que um determinado produto ao longo da sua vida util, passa por uma sucessao de estados,
lugares, condicoes, entidades, podendo ser transformado, destruıdo, agregado ou apenas deslocado.
Registar estas ocorrencias e o passo inicial para qualquer processo de rastreabilidade. Se considerar-
mos o facto de, ser comum um produto deslocar-se por diversos paıses e organizacoes, desde a sua
producao ate chegar ao consumidor final, a dificuldade de controlar o ciclo de vida do produto aumenta
2
significativamente (Figura 1.1).
Para resolver este problema surgiram os primeiros sistemas de rastreabilidade que se baseavam no
conceito de pedigree ou adoptavam um modelo centralizado de informacao.
1.1 Rastreabilidade AS-IS
Actualmente existem dois modelos de arquitecturas de rastreabilidade. Um deles recorre a construcao
de registos electronicos certificados, os pedigrees, que acompanham o produto ao longo de toda a cadeia.
O segundo modelo e definido por arquitecturas proprietarias, fechadas onde um dos elementos controla
e gere a gestao da rede, impondo regras aos restantes.
1.1.1 Rastreabilidade via Pedigree
Os pedigrees sao entao “um registo certificado que contem informacao sobre (. . . ) produtos, transaccoes,
distribuidores, destinatarios e assinaturas.” [7].
Os pedigrees visavam manter um historico de toda a vida do objecto de forma a responder as se-
guintes questoes:
• Como controlar as condicoes (temperatura, humidade, etc.) do produto ao longo da cadeia?
• Qual e o historico e informacao detalhada das materias primas do produto?
• Que produtos partilham o mesmo espaco?
• Como encontrar produtos perdidos?
• Como se pode optimizar a cadeia de fornecimento?
O proposito destes registos era manter informacao sobre os objectos, permitindo uma analise e
despistagem de eventuais anomalias.
Estes sistemas cedo comecaram a mostrar as suas falhas. O facto de o pedigree registar toda a
informacao de um determinado produto, torna-o algo volumoso e de dificil gestao. A proteccao da
informacao e feita recorrendo a cifras, que protegem a totalidade da informacao, impossibilitando uma
filtragem dos dados por tipologia e destinatario. Mas o maior problema destes sistemas prende-se pelo
facto de o pedigree acompanhar o produto, sendo impossıvel obter informacoes sobre o mesmo, quando
este deixa de estar sobre o controlo da organizacao. Ou seja assim que o produto abandona a organizacao
deixa de o conhecer. Se pretender identificar o estado actual do produto, tem que reconstruir toda a
cadeia deste e basta um dos elementos estar inacessıvel para impedir a realizacao das pesquisas.
3
Na figura 1.2 e possıvel observar um exemplo de uma rede que recorre a pedigree, e esta exemplifi-
cado o crescimento da informacao ao longo da cadeia. A cadeia exemplificada e de reduzidas dimensoes
e o tamanho do registo sera proporcional ao tamanho da mesma.
Figura 1.2: Uma cadeia de fornecimento com registos pedigree e respectivo crescimento da informacao
1.1.2 Rastreabilidade via Redes proprietarias
A segunda solucao actual e a utilizacao de repositorios centralizados, controlados por um dos elementos
da rede, que sendo o player mais importante da rede, consegue impor regras aos demais. Os outros
elementos sao obrigados a participar na rede, partilhando informacao de forma a alimentar o sistema.
Geralmente nao tem acesso a nenhuma informacao produzida por si ou pelos restantes elementos da
rede.
A utilizacao de repositorios centralizados tem se mostrado cada vez mais instavel, pela quantidade
de dados que e necessario processar e ainda pelo facto de todo o sistema assentar sobre um unico ponto
de informacao.
Este tipo de sistemas e largamente utilizado na industria automovel, onde o fabricante dos au-
tomoveis e o proprietario do sistema e impoe a sua utilizacao aos diversos fornecedores [8]. O facto de
este ser um modelo, onde um dos elementos e o proprietario do sistema e principal ’stakeholder’ ate-
nua bastante a necessidade de modificacao dos sistema, pela propria estabilizacao das redes de forneci-
mento. O que acontece nestes casos e que a maioria dos utilizadores tem que se adaptar a um sistema,
em vez de ser o proprio sistema, a adaptar-se aos utilizadores. Enquanto este modelo e aplicavel nestas
cadeias de distribuicao, peca em situacoes em que a cadeia apresenta comportamentos dinamicos.
Na realidade, o modelo utilizado na industria automovel, nao e aplicavel a longo prazo nas re-
des actuais, pelas caracterısticas que estas possuem. O dinamismo das redes de fornecimento obriga a
que as organizacoes necessitem de se adaptar de forma agil, mudando processos, operacoes e fluxos.
Estas adaptacoes sao realizadas recorrendo a ferramentas tendo um impacto na informacao que produ-
zem e distribuem. O principal desafio surge desta forma, quando uma organizacao tem que partilhar
4
informacao com a rede por onde circula o seu produto, devendo adaptar o seu comportamento ao com-
portamento da rede. So assim e possıvel a um consumidor conhecer toda a historia do produto que esta
a comprar.
Na figura 1.3 e visıvel um exemplo de uma rede de rastreabilidade com informacao centralizada,
onde o elemento central agrega toda a informacao, ficando esta inacessıvel para os restantes elementos,
cuja funcao e exclusivamente alimentar o repositorio.
Figura 1.3: Uma cadeia de fornecimento com informacao centralizada
1.2 Rastreabilidade To Be
O objectivo deste trabalho sera criar uma arquitectura alternativa, baseada nos sistemas actuais, que
resolva os seguintes desafios:
• Uniformizar a informacao dos diversos sistemas;
• Definir primitivas para a realizacao de pesquisas de rastreabilidade;
• Definir algoritmos de pesquisa;
• Definir sistemas de autenticacao e autorizacao;
• Garantir a escalabilidade do sistema;
• Mitigar utilizacoes abusivas do sistema;
• Definir diferentes nıveis de pesquisa consoante o papel que desempenha na cadeia;
• Definir e alterar permissoes de acesso aos dados.
Adicionalmente, o modelo proposto devera ter em conta as ultimas directivas e orientacoes respei-
tantes a Internet of Things [9] [10]:
5
• Permitir a partilha de informacao entre parceiros;
• Definir e alterar permissoes de acesso;
• O fluxo de mensagens simular o fluxo do produto na cadeia de fornecimento;
• Manter-se operacional mesmo que existam falhas num dos elementos;
• Aceder informacao nos sistemas de cada entidade em vez de manter copias locais da mesma;
• Suportar uma linguagem de negocio para definir permissoes de acesso, nıvel de detalhe na
informacao, etc;
• Ser capaz de processar grandes quantidades de dados.
O objectivo sera construir uma rede de entidades, que participem activamente no processo de ras-
treabilidade de produtos, registando e disponibilizando informacao, que permita a qualquer elemento
participante, a execucao de pesquisas de objectos, esteja este a montante ou a jusante da posicao actual
do objecto. Na figura 1.4 e visıvel como devera ser a arquitectura dos proximos sistemas. Os sistemas
devem ser formados por entidades (Peer1 a Peer5) que possuem dados sobre os objectos que observam
(A a E). Quando um elemento pretende rastrear um determinado produto devera inquirir apenas os
elementos que estiveram associados ao passado desse objecto.
Figura 1.4: Sistema de rastreabilidade proposto
1.3 Estrutura do documento
O trabalho aqui apresentado, abordara a problematica identificada propondo uma solucao global que
resolva todos os assuntos previamente identificados. O documento esta organizado em quatro seccoes
principais. Inicia-se neste capıtulo com a introducao do problema e definicao de objectivos, seguindo-se
de um segundo capıtulo onde se apresenta o estado de arte das solucoes e tecnologias actuais. O terceiro
6
capıtulo sera a apresentacao da nova arquitectura. O documento termina com a avaliacao da solucao
apresentada e respectivas conclusoes.
Durante a execucao deste trabalho desenvolveram-se algumas actividades em paralelo, que nao es-
tando directamente relacionadas com o tema do trabalho desenvolvido foram importantes durante fases
especıficas do mesmo. Um exemplo destas actividades foi a construcao de um simulador de sistemas
RFID, que levou a escrita de um paper para uma conferencia da especialidade. Estes trabalhos auxilia-
res encontram-se como anexos deste documento devendo ser consultados para melhor compreensao de
alguns fundamentos e decisoes tomadas ao longo do trabalho.
7
8
2Enquadramento
Esta seccao ira contextualizar o problema, descrevendo o estado actual dos sistemas da area. Pretende-se
realizar uma breve introducao as tecnologias e conceitos que se irao utilizar na descricao da arquitectura
e na apresentacao da solucao.
2.1 Internet of Things
O conceito “Internet of Things (IoT)” e um conceito recente, e deriva de uma necessidade de se efectuar
um cruzamento entre os objectos no mundo real e no mundo virtual. Uma descricao sucinta classificaria
a “Internet of Things” como “uma infra-estrutura dinamica e global de redes com capacidades de auto-
configuracao baseadas num standard e protocolos de comunicacao inter-operaveis onde ‘coisas’ fısicas
e virtuais tem identidades, atributos fısicos, e personalidades virtuais, usam interfaces inteligentes, e
estao perfeitamente integradas com a rede de informacao” [11].
Segundo a visao da IoT cada objecto deve possuir uma identificacao universal e enderecamento
tambem universal. A identificacao pode ser feita recorrendo a identificadores EPC e o enderecamento
sera feito recorrendo a enderecos IPv6. Ao aceder-se a um objecto atraves da rede passara a ser possıvel
comunicar com este e obter o historico e estado actual deste. Ou seja os objectos fısicos tornam-se
elementos de uma rede virtual, criando uma “ponte” entre esta e o mundo fısico. Esta aplicacao permite
que os produtos possuam uma identificacao universal, que e identica para todas as entidades ao longo
da cadeia de fornecimento. A interseccao de duas realidades ate agora distintas levantou inumeros
problemas e obrigou ao estabelecimento de regras. A Uniao Europeia tomou a iniciativa e definiu um
conjunto de requisitos que a “Internet of Things” deve garantir [10]:
• Privacidade e proteccao de dados pessoais;
• Confianca, aceitacao e seguranca da informacao;
• Normalizacao dos sistemas;
• Permitir a pesquisa e desenvolvimento contınuo;
• Abertura a inovacao e desenvolvimentos futuros.
Sendo um conceito ainda em desenvolvimento alguns destes pontos ainda nao estao totalmente defini-
dos. A aplicacao do conceito “Internet of Things” obriga a utilizacao de nova tecnologia, que permita
que o objecto se torne parte da rede. E neste campo que o EPCglobal e o RFID tomam a lideranca.
2.2 Sistemas RFID
A maioria dos sistemas de rastreabilidade actuais utiliza codigos de barras para identificar o produto.
Esta identificacao e feita essencialmente ao nıvel da categoria, mas falham na classificacao do lote e item
de lote. Para se efectuarem essas classificacoes e necessario recorrer a codigos de barras extras, ou a
matrizes de identificacao [12] de forma a criar um numero de combinacoes suficiente para identificar
unıvocamente cada elemento. A tecnologia RFID pretende resolver os problemas que esses sistemas
enfrentam, disponibilizando ainda alguns avancos tecnologicos, que facilitam a tarefa de identificacao
de itens. Um sistema tıpico de RFID e composto por tres partes [13] (figura 2.1):
• Etiqueta – Um identificador fısico colocado no produto. E activada pela energia de um campo
electromagnetico e emite um sinal que contem a informacao.
• Um leitor – Os leitores tem uma dupla funcao. Criam o campo electromagnetico que activa as
etiquetas, e recebem a informacao emitida por esta.
• Uma infra-estrutura de software/hardware – Esta infra-estrutura e onde ficam registados e dispo-
nibilizados todos os eventos registados pelos leitores.
Figura 2.1: Um sistema RFID tradicional
Uma descricao detalhada das caracterısticas de cada componente sera dada posteriormente. Um
sistema RFID face a um sistema de codigos de barras apresenta as seguintes vantagens [14] [12]:
10
Tipo Fonte energetica Alcance Capacidade de processamentoActiva Bateria interna Elevado AltaSemi-Activa Bateria interna activada Medio a elevado Media
pelo campo electromagneticoPassiva Campo electromagnetico Baixo Baixa
Tabela 2.1: Categorias de antenas e comparacao relativa das respectivas caracterısticas [9]
• O objecto nao precisa de estar visıvel para ser detectado
• As leituras podem-se fazer a grandes distancias
• Podem fazer-se multiplas leituras em simultaneo
• Tem capacidade de escrita / leitura nas etiquetas
• E mais complicado destruir a informacao das etiquetas e falsificar as mesmas.
Neste momento comparando as duas solucoes a unica desvantagem que existe e o preco das etiquetas
que e muito elevado quando comparado com o preco de imprimir um codigo de barras.
2.2.1 Etiquetas RFID
As etiquetas RFID sao o objecto principal neste tipo de sistemas. Sao compostas por dois compo-
nentes, uma antena e um micro-chip. Estas sao categorizadas em tres categorias consoante o tipo de
fonte energetica que usam (Tabela 2.1). O custo elevado das etiquetas foram o principal entrave a
implementacao destes sistemas, optando-se por identificar apenas itens de valor elevado. A progres-
siva reducao do custo tem motivado novas organizacoes, em especial as pequenas e medias empresas, a
utilizar os mesmos. Por outro lado, as antenas sofrem ainda grandes perturbacoes no seu normal funci-
onamento, quando proximas de zonas metalicas, que influenciam bastante o campo magnetico utilizado
pelas mesmas, reduzindo desta forma a capacidade e fiabilidade das mesmas. A EPCglobal efectua uma
caracterizacao distinta das etiquetas, separando estas em cinco classes e duas geracoes (Tabela 2.2). Esta
ultima categorizacao das etiquetas fara mais sentido, uma vez que as etiquetas sao classificadas conside-
rando nao so as caracterısticas tecnicas e capacidades mas tambem considerando os custos das mesmas.
Existem neste momento duas geracoes de componentes, operando a primeira geracao com 64 ou 96
bits de informacao, e a segunda geracao entre 96 e 256 bits de informacao. A segunda geracao ainda se
encontra em fase de desenvolvimento.
11
Classe de etiqueta CaracterısticasClasse 0 Passiva, Leitura apenasClasse 1 Passiva, Escrita Unica, Multiplas leiturasClasse 2 Passiva, Multiplas leituras e escritasClasse 3 Semi-ActivaClasse 4 Activa
Tabela 2.2: Classes de etiquetas (EPCglobal 2007)
2.2.2 Leitores RFID
Os leitores RFID sao os dispositivos que comunicam com as antenas. Criam o campo electromagnetico
que activa as antenas, e recebem a informacao contida nos micro-chips, que mais tarde descodificam.
Os leitores podem ser fixos ou moveis. Os leitores fixos, sao colocados normalmente em locais de pas-
sagem obrigatoria dos produtos, como linhas de montagem. Ja os leitores moveis tem a vantagem de
poderem ser utilizados em situacoes onde nao existe local fixo de passagem de bens. Os leitores sao
influenciados pelo ambiente que os rodeia, nao devendo estar instalados junto de zonas metalicas, uma
vez que estas influenciam bastante a qualidade das leituras. Uma outra caracterıstica dos leitores, e
efectuarem multiplas leituras simultaneamente, sendo necessario tratar leituras replicadas. Devido a
esta caracterıstica o sistema de informacao tem que ser capaz de tratar grandes volumes de dados que
vao ser gerados pelos leitores. As taxas de sucesso nas leituras de um leitor dependem dos protocolos
utilizados e da distancia entre o leitor e a etiqueta. As taxas de sucesso dos leitores actuais variam de
90% para curtas distancias (60 cm), para cerca de 10% a distancias de 6 metros para etiquetas passivas. A
distancias curtas e com 16 etiquetas um leitor pode efectuar ate cerca de 200 leituras por segundo [15].
2.2.3 Sistemas de Informacao RFID
Os sistemas de informacao de RFID sao responsaveis por armazenar a interpretar os dados recebidos
pelos leitores RFID. Sendo um sistema de informacao tem que disponibilizar formas de consultar os
dados, processar os mesmos, e manter um registo de todas as actividades detectadas pelos leitores. De-
vido ao elevado numero de leituras realizadas pelos leitores, e a elevada quantidade de objectos/leitores
existentes num ambiente controlado, estes sistemas tem que ter a capacidade de armazenar e processar
grandes volumes de dados. A principal utilizacao destes sistemas sera realizar pesquisas sobre o estado
(actual ou anterior) de um determinado objecto, receber notificacoes e registar eventos. A utilizacao
destes sistemas normalmente tem impacto a dois nıveis [16]:
• Gestao de dados
• Integracao com os restantes sistemas
12
A forma como os dados sao administrados e alterada de forma a que estes tenham uma
representacao unica para toda a organizacao onde o sistema sera implementado. Uma vez que o objecto
a identificar e o mesmo em todos os ambientes controlados, este tera que ter a mesma representacao
ao longo do sistema. Outro factor importante e o detalhe da informacao disponibilizada sobre um de-
terminado produto. Este aspecto adquire particular importancia em ambientes partilhados, em que
outras entidades nao devem ter acesso a informacao total de um objecto. A integracao do sistema de
informacao RFID com os sistemas existentes e igualmente importante, pois um sistema de identificacao
de objectos, e utilizado por sistemas de controlo de stocks, planeamento logıstico, etc. A instalacao des-
tes sistemas pode obrigar a renovacoes na infra-estrutura tecnologica para permitir o acesso a grandes
volumes de dados. Para que a integracao seja bem sucedida os dados podem ser transformados de
forma a que seja compreendidos pelos restantes sistemas.
2.3 EPCglobal
A EPCglobal Network e um consorcio de organizacoes que promovem a utilizacao de sistemas RFID,
para identificacao de produtos. E objectivo da EPCglobal Network definir standards abertos, que pos-
sam ser utilizados em ambiente industrial e desta forma incentivar a partilha de informacao pela cadeia
de fornecimento [17]. Entre os standards definidos pela EPCglobal Network, encontramos standards
para todas as fases que a deteccao de uma etiqueta passa, desde os dados colocados na etiqueta, pas-
sando pelas caracterısticas dos leitores, interfaces para eventos, etc. (figura 2.2).
Neste momento apenas dois elementos da arquitectura global estao por definir sendo eles o Disco-
very Services e o Tag Protocol EPC HF. O primeiro encontra-se no nıvel Exchange que tem como objectivo
a partilha de informacao entre entidades, ja o segundo encontra-se no nıvel identify que tem como objec-
tivo a identificacao de produtos pelas etiquetas.
No ambito deste trabalho tomam particular interesse o EPC (Electronic Product Code), o EPCIS (
Electronic Product Code Information System) o ONS (Object Naming Server) e o Discovery Services.
2.3.1 EPC
EPC e a sigla utilizada para designar Codigo Electronico de Produtos. Este codigo e utilizado para
efectuar uma identificacao de objectos, com um nıvel de granularidade maximo igual a unidade. A
capacidade oferecida pelo EPC de identificar a unidade, num lote, linha de montagem, foi considerada
como uma tecnologia substituta dos codigos de barras [18]. A realidade e que o preco actual das etique-
tas RFID impede esta concretizacao na sua totalidade, permite no entanto obter uma antevisao do que
podera ser o futuro. Sendo o objectivo do EPC identificar todos os objectos, este tem que considerar as
13
Figura 2.2: Framework EPCGlobal
classificacoes actualmente utilizadas e permitir extensoes de forma a garantir a utilizacao a longo prazo
do mesmo. Um codigo EPC esta dividido em 4 seccoes (Figura 2.3), e permite identificar ate [19]:
• 268 milhoes de produtores
• 16 milhoes de classes de objectos por produtor
• 6.8 x 109 objectos por classe
Figura 2.3: Estrutura do EPC[19]
Uma das caracterısticas interessantes do EPC, e o facto de poder ser utilizado para identificar con-
tentores, paletes, eventos de montagem e agregacao. Um carro poderia ser identificado por cada um
14
Numero EPCO que Dados transaccionais
Dados manufacturaOnde? LocalizacaoQuando? Tempo do evento
Tempo de registoPasso do processo de negocio
Como? Estado do objectoCondicoes actuais
Tabela 2.3: As quatro perguntas que o EPCIS pretende responder
dos objectos que o constitui, ou como uma agregacao de objectos, tendo o seu proprio EPC, que estaria
associado a essa agregacao. Na idealizacao do EPC varias opcoes foram ponderadas, tendo-se optado
por simplificar ao maximo a norma e permitir extensoes a mesma, de forma a garantir a operaciona-
lidade do mesmo a longo prazo. As principais simplificacoes efectuadas em relacao aos metodos de
identificacao ja existentes foram [19]:
• Minimizar ou retirar a informacao embebida nos codigos, como peso, dimensoes, etc.
• Retirar a classificacao de produtos em categorias, visto que estas podem nao ter a mesma
classificacao, ao longo da vida de um produto.
• Minimizar a utilizacao de meta-dados nos codigos EPC
• Dar preferencia a identificacao electronica que a identificacao por humanos
• Separar a identificacao de qualquer protocolo de comunicacao existente.
O EPC pretende deste modo, identificar todos os objectos fısicos, tendo estes uma representacao den-
tro e fora do mundo virtual. Existem alguns trabalhos [19] que estudam a possibilidade de utilizar
enderecamentos IPv6 para ser possıvel comunicar directamente com os objectos. Apesar deste ser o
proximo passo, os objectivos principais da ideia “Internet of Things” ja estao resolvidos com a utilizacao
de codigos EPC.
2.3.2 EPCIS
O EPCIS, e um standard para Servicos de Informacao de Codigos Electronicos de Produtos. Tem como
principal objectivo, definir metodos de pesquisa de informacao sobre mobilidade de produtos. Pretende
atingir este objectivo atraves da resposta a quatro perguntas [20]:
Existem 4 tipos de eventos EPCIS (Tabela 2.3) com os quais e possıvel definir o estado de qualquer
objecto em qualquer instante, recorrendo aos codigos EPC.
15
Tipo de Evento ObjectivoEPCISEvent Classe generica para todos os eventosObjectEvent Representar eventos que aconteceram em uma ou mais
entidades denotadas por EPCsAggregationEvent Representar eventos de agregacao a duas ou mais entidades
denotadas por EPCs e que estao fisicamente restringidas aomesmo espaco(p.e. produtos colocados numa palete passama ser identificados pela palete).
QuantityEvent Representa eventos relacionados com um grupo deentidades identificados por um unico EPC e onde asentidades individuais nao estao especificadas
TransactionEvent Representa eventos onde uma ou mais entidades denotadaspor EPCs, se associam ou dissociam com um ou maistransaccoes de negocio.
Tabela 2.4: Eventos EPCIS
O EPCIS disponibiliza dois meios para controlo dos eventos. Um para registo dos mesmos, a Cap-
ture Interface, e outro para obtencao de informacao referente a eventos registados a Query Interface.
A Capture Interface permite que multiplos eventos sejam registados de uma unica vez, e a informacao
que recebe e uma lista de eventos EPCIS. A Query Interface disponibiliza dois tipos de servicos, o con-
trolo de queries e a execucao de queries. A execucao de queries permite que qualquer cliente efectue
pesquisas sobre um determinado codigo EPC, obtendo como resposta todos os eventos associados a
esse EPC. A interface de controlo de queries permite que um cliente administre a subscricao de que-
ries. Ao subscrever-se uma query relacionada com um codigo EPC, sempre que nova informacao seja
gerada sobre esse codigo EPC, e que corresponda aos criterios da query subscrita, esta informacao e
automaticamente reencaminhada para um local designado pelo cliente. Esse local tem que implementar
Query Callback Interface. Toda a comunicacao realizada com o EPCIS, recorre a esquemas XML para
representacao de dados.
2.3.3 ONS
O ONS e um elemento da arquitectura EPCGlobal. Este elemento replica a funcionalidade de um
DNS -Domain Name System, aplicando-a ao universo dos objectos. Enquanto um DNS e um sistema
hierarquico de resolucao de nomes de domınios de rede para enderecos IP, o ONS devera utilizar um
sistema semelhante ao DNS para resolver identificadores EPC nos respectivos servicos disponıveis. Ou
seja o ONS devera para um determinado EPC, retornar um service endpoint acessıvel numa rede associ-
ado com o EPC em causa, identificando desta forma o responsavel por este. O ONS nao devolvera ne-
nhuma informacao sobre o objecto mas antes a localizacao onde essa informacao podera ser obtida [21]
.
16
Para tal e necessario que formatos da query e da resposta ao servico ONS, devem obedecer aos
standards DNS, ou seja, o EPC sera convertido para uma estrutura hierarquica domınio-nome e os
resultados devem ser registos DNS com formato valido [21]
2.3.4 Discovery Services
Os standards de Discovery Services do standard EPCGlobal estao neste momento em desenvolvimento.
Pretende-se que este elemento permita descobrir e obter toda a informacao relevante, a qual um
participante esteja autorizado a aceder, onde parte dessa informacao esteja sob controlo de outros parti-
cipantes com os quais nao existiu nenhuma relacao de negocio previa 1.
Ou seja os discovery services pretendem permitir estabelecer relacoes de negocio e partilha de
informacao entre dois elementos, que desconhecam a existencia um do outro, mas que possuem
informacao de interesse mutuo.
O recurso a Discovery Services simplifica o processo de partilha de informacao, ao oferecer um
servico que liga toda a informacao sobre produtos, enquanto estes percorrem a cadeia de fornecimento
[22].
Comparativamente com os ONS, o recurso a Discovery Service permite o desenvolvimento mais
eficiente e robusto de aplicacoes de Track e Trace [23]
2.4 Rede Federada
Um dos conceitos importantes deste documento e o conceito de federacao de entidades. Uma federacao
consiste num grupo de entidades, que partilham entre si um conjunto de servicos comuns, e onde a
informacao se encontra distribuıda de forma fraccionada. Cada entidade da federacao tem ao seu dis-
por, a sua propria informacao, e a informacao distribuıda pela federacao, podendo aceder a esta directa-
mente em cada entidade parceira, ou atraves de um ponto central. O funcionamento de uma federacao
e a partilha dos seus servicos esta fortemente dependente das relacoes de confianca entre os parceiros.
Estas relacoes sao estabelecidas inicialmente por um objectivo comum e pela identificacao de mais va-
lias na partilha de servicos. Apos este passo inicial e necessario estabelecer nıveis de seguranca que
permitam a partilha de informacao. A seguranca e garantida recorrendo a tecnicas de identificacao de
entidades pela federacao e cifra de mensagens entre os parceiros. Geralmente e associado um Discovery
Service as federacoes para permitir identificar quais os servicos disponibilizados por esta para o exterior.
1EPCGlobal - http://www.gs1.org/gsmp/kc/epcglobal/discovery
17
Resumindo, uma federacao e um grupo de entidades que partilham recursos, com elevada confianca, e
disponibilizam um conjunto de servicos para o exterior.
As redes de rastreabilidade federadas apresentam uma grande vantagem comparativamente com
as redes distribuıdas. Segundo [8], as redes federadas apresentam um custo de entrada superior e
crescimento linear, quando comparadas com as redes distribuıdas que apresentam baixos custos de
entrada mas um crescimento exponencial. Em media o sistema torna-se mais economico quando se
ultrapassam as tres pesquisas efectuadas por um determinado objecto.
2.5 Rastreabilidade
A rastreabilidade refere-se a capacidade de se reconstruir a vida de um objecto. Esta capacidade e bas-
tante utilizada em cadeias de fornecimento, onde as diversas entidades envolvidas pretendem, saber
onde esta um produto, onde esteve e finalmente a composicao do mesmo. Estas tres perguntas sao
as mais importantes em sitemas de controlo de produtos e cadeias de fornecimento. Em 2007 surgiu
um projecto, que teve como objectivo, analisar os sistemas de rastreabilidade, numa perspectiva de
optimizacao das cadeias. Este projecto desenvolveu modelos que permitiam antecipar qual o proximo
estado de um objecto, atraves da analise de informacao anterior. Este projecto iniciou-se pelo levanta-
mento das operacoes de negocio que um sistema deveria responder. Seguidamente apresentam-se essas
mesmas questoes, a tıtulo meramente informativo, e como justificacao da importancia e utilidade deste
tipo de sistemas [24] :
• Qual o historico de deteccoes de um determinado item?
• Por que parceiros passou o elemento?
• Quando e que o item chega ao destino?
• Quem acedeu ao produto?
• Qual o estado do objecto?
• O objecto passou na posicao?
• O objecto foi consumido ou destruıdo?
• Qual o destinatario do objecto?
• Caminhos alternativos/autorizados?
• Qual a validade do produto?
• Quando foi produzido?
18
• Quem alterou o produto?
• Quantas alteracoes sofreu o produto?
• Quais as materias-primas do produto?
• O produto encontra-se agrupado?
• Qual a proxima localizacao provavel do produto?
• Quais os produtos perdidos?
Note-se que muitas das perguntas aqui destacadas apenas se conseguem responder num contexto
de federacao. Este trabalho focar-se-a na resolucao das tres perguntas que a seguir se descrevem, em
redes federadas, onde um peer pode ver o seu acesso restringido.
2.5.1 Bill of Materials
O Bill-of-materials de um objecto e ”na sua forma mais simples uma lista de materias-primas(..) compo-
nentes,partes e quantidades necessarias para produzir um produto” [25]. Com a evolucao das cadeias
de fornecimento surgiram, diversas utilidades para BOM das quais se destacam quatro:
• Engineering Bill of materials - como o produto e desenhado
• Sales Bill of materials - pedido de compra de produto
• Manufacturing Bill of materials - como o produto foi construıdo
• Maintenance Bill of materials - como o produto foi mantido.
Neste trabalho sera dado destaque ao Bill-of-materials de construcao, sendo que o de manutencao e
identico, apenas apresenta uma diferenca em relacao aos eventos que considera. Ou seja enquanto para
o bill-of-materials de fabrico apenas interessam os eventos ocorridos ate a data de construcao do objecto,
para o bill-of-materials de manutencao interessam todos os eventos ocorridos, independentemente da
data.
Um dos problemas associados a construcao e partilha de Bill-of-materials e a falta de standard para
a representacao do mesmo. Existem diversas solucoes, cada organizacao tem a sua representacao, e
por vezes mais que uma. Para resolver este problema surgiu um conselho de experts que avancou com
algumas propostas para o mesmo.
Os principais erros detectados passavam por [26]:
19
• Informacao Incompleta
• Dados inconsistentes
• Dados incorrectos
Como necessidade identificaram os seguintes aspectos que deveria ser possıvel obter numa BOM:
• Identificacao do componente
• Identificacao do produtor
• Quantidade
• Descricao
• Sub Componentes - Identificacao de hierarquias
2.5.2 Track
O track de um produto, e provavelmente uma das pesquisas mais efectuadas, em cadeias de forneci-
mento, actualmente. Este refere-se a capacidade de identificar qual foi a ultima localizacao conhecida
de um determinado objecto. E bastante utilizado no sector da distribuicao, especialmente com o cresci-
mento dos portais web onde o cliente pode consultar o local actual da sua encomenda.
O resultado de um track, deve conter pelo menos, o local e a hora da ultima visualizacao do produto.
2.5.3 Trace
Ao contrario de uma pesquisa de track, uma pesquisa Trace, tem o objectivo de recolher informacao
sobre todas as visualizacoes de um determinado objecto. Representa deste modo um historico de locais,
por onde o objecto foi observado.
O resultado e entao uma lista ordenada, em que cada elemento contem o local e timestamp da
observacao.
O trace e o track de um produto sao bastante semelhantes podendo-se considerar o track como uma
simplificacao do trace. Uma vez que o trace providencıa um historico de visualizacoes, o resultado mais
recente deste historico, correspondera ao resultado do track desse mesmo produto. Esta caracterıstica
torna-se bastante util para testar a execucao dos algoritmos.
20
2.6 rfrbNet -Rede Federada de Rastreabilidade de Bens
A rfrbNet foi um projecto inovador desenvolvido pela Link Consulting. Este projecto pretendeu dispo-
nibilizar uma solucao de rastreabilidade de produtos para PME - Pequenas e Medias Empresas.
Sendo as PME o mercado alvo deste projecto, este adquire algumas caracterısticas especiais sendo
estas:
• Baixo custo de entrada
• Disponibilizacao de diversos modelos de participacao
• Facilidade de expansao do sistema
O baixo custo de entrada torna-se uma caracterıstica obvia devido a pequena dimensao das
empresas que na maior parte das situacoes tambem tem um reduzido orcamento associado. A
Disponibilizacao de diversos modelos de participacao surge do facto de nao se querer impedir a
participacao nas redes de rastreabilidade de elementos que nao possuam ou consigam adquirir a to-
talidade dos elementos de um sistema RFID ja descrito anteriormente. Idealmente bastaria que o parti-
cipante possua um leitor e uma ligacao a rede para participar na rede. Esta poderia albergar os diversos
repositorios, aplicacoes de captura, etc. Os eventos capturados pelo leitor, seriam reencaminhados direc-
tamente para a rede ficando esta a cargo do seu processamento. No limite um participante poderia nem
ter um leitor RFID se o seu papel fosse meramente de cliente, devendo apenas utilizar uma aplicacao
cliente para realizar as pesquisas. Finalmente surge a facilidade de expansao do sistema. Sendo este um
sistema inovador, e expectavel que numa fase inicial seja utilizado por um numero reduzido de partici-
pantes, mas que apos a confirmacao da sustentabilidade do mesmo e dos benefıcios obtidos, o numero
de utilizadores cresca substancialmente, desta forma o sistema tem que ser escalavel.
2.7 Cen�ario
A presente seccao ira apresentar o cenario de teste utilizado em todo o trabalho. O cenario foi desenhado
de forma a gerar todos os casos de uso que se pretendem simular, ou seja , as diversas perguntas de
rastreabilidade e respectivas dificuldades.
O cenario escolhido e baseado na cadeia de fornecimento de um produto de utilizacao diaria,
o computador portatil. O computador portatil foi identificado como um objecto ideal, devido a sua
constituicao. Um computador e constituıdo por diversos componentes, provenientes de diversas fon-
tes, podendo cada um destes componentes ser ele proprio um componente complexo. Esta estrutura
21
complexa de elementos, permitiu construir um cenario com alguma profundidade onde se desenrolam
as perguntas de rastreabilidade que pretendemos responder.
Na tabela que se segue e possıvel observar os principais componentes que constituem um compu-
tador e quais foram considerados para este trabalho.
A construcao do portatil e respectiva cadeia de fornecimento foi mapeada sobre 5 entidades princi-
pais:
• Fabrica de componentes de portateis designada de barebones;
• Fabrica de portateis designada de laptops;
• Dois centros de distribuicao designados de DC1 e DC2 respectivamente;
• Uma loja de produtos tecnologicos designada de store.
Optou-se pela duplicacao de uma entidade de forma a gerar diferentes possibilidades de caminhos
e ainda criar uma situacao de conflito de interesses na rede, uma vez que estas entidades embora coo-
perando na rede, competem entre si.
Na figura 2.7 e representada a estrutura simplificada da rede de fornecimento criada para fins de
teste.
Figura 2.4: Diagrama da rede de distribuicao do cenario criado para fins de teste
Foi considerado que a saıda de cada fabrica os componentes dos portateis sao agregados em caixas
de 10 componentes e posteriormente, 5 caixas sao agregadas numa palete. Esta palete e inserida numa
carrinha de transporte que transporta o produto desde a fabrica Barebones ate um dos dois centros de
distribuicao. Em ambos os centros de distribuicao, qualquer palete que entre sera sempre destruıda, os
produtos armazenados, e posteriormente e recriada numa nova palete, para transporte dos produtos
ao seu destino final. Na fabrica de portateis, todas as paletes recebidas sao destruıdas e os respectivos
componentes armazenados. Sempre que existir um numero mınimo de componentes suficiente para a
construcao de um portatil esta e iniciada. Durante a construcao todos os componentes sao agregados no
portatil, que sera agregado a uma caixa juntamente com uma bateria e carregador. A caixa de portatil
segue para o armazem onde e agregada numa Box juntamente com outras quatro caixas. Um conjunto
de Box e agregado numa palete, que seguira para uma loja passando antes por um centro de distribuicao.
Na loja todos contentores sao destruıdos colocando-se os produtos em prateleiras para venda.
22
Adicionalmente considerou-se que cada peer da rede tem a sua estrutura fısica de armazenamento
de dados, repositorio EPCIS, que disponibiliza para os restantes.
23
24
3Arquitectura
Este capıtulo apresentara a arquitectura da solucao e os diversos passos seguidos para a obter. Este
trabalho teve como fundamentos os trabalhos realizados por Agrawal [27], ao nıvel de algoritmos de
rastreabilidade, e por Karin Murthy e Christine Robson [8] no que diz respeito a analise de desempenho
dos diversos sistemas.
Apesar de se basear no trabalho desenvolvido por Agrawal, existem algumas diferencas na aborda-
gem. Agrawal realizou um estudo sobre a realizacao de rastreabilidades em bases de dados distribuıdas
definindo algoritmos para as principais perguntas de rastreabilidade. No seu modelo cada participante
na rede e envolvido no processo de pesquisa. O processo de pesquisa inicia-se com a escrita de uma
consulta que e enviada a um elemento da rede. Este elemento processa o maximo de informacao que
consegue, reescreve a consulta que reencaminha para os proximos elementos da cadeia. No final toda a
informacao e agregada, obtendo-se as respostas pretendidas.
Este tipo de processamento levanta alguns problemas no contexto deste trabalho:
• Obrigatoriedade de participacao no processo mesmo quando nao existe interesse na partilha de
informacao;
• Todos os participantes tem que ter o mesmo acesso a informacao nao podendo ser colocadas
restricoes no acesso a dados sob o risco de impossibilitar a execucao dos algoritmos;
• A query e propagada em vez de ser resolvida pelo cliente;
• O elemento que realiza o pedido de informacao, podera nao ser o utilizador final da mesma.
Estes problemas levaram a uma redefinicao dos algoritmos, que embora semelhantes, devem re-
solver este problema no contexto da nova arquitectura. Os modelos relacionais e logicos definidos por
Agrawal foram igualmente simplificados removendo toda a informacao desnecessaria para este traba-
lho.
De forma a realizar esta redefinicao dos algoritmos, iniciou-se o processo com a identificacao das
novas premissas e elementos fundamentais da rede de rastreabilidade. Aqui foram identificados os ele-
mentos como unidades basicas de informacao, algoritmos de resolucao de pesquisas e funcionalidades
obrigatorias a disponibilizar pela federacao. Apos esta definicao de elementos e estruturas fundamen-
tais e necessario mapear os mesmos com as tecnologias existentes. Deste mapeamento resultarao duas
arquitecturas alternativas, que serao analisadas, e uma destas sera seleccionada como fundamento para
o restante trabalho.
Findo este processo inicial, e necessario dotar a arquitectura dos componentes e meios que permi-
tirao aplicar as polıticas de partilha de informacao. O objectivo destas polıticas e garantir a agilizacao
dos processos, e atribuir dinamismo a arquitectura que devera estar capacitada de modificar o seu com-
portamento em funcao de diversas variaveis.
3.1 Rastreabilidade
A importancia e complexidade da rastreabilidade de produtos foi destacada nos capıtulos anteriores.
De forma a resolver os problemas e dificuldades identificados, foi seguido um processo cıclico de refina-
mento. Os tres topicos a desenvolver(Estruturas de dados, Algoritmos e Arquitecturas), foram definidos
seguindo uma abordagem top-down, iniciada sempre no nıvel conceptual,seguido de um nıvel logico e
terminando num nıvel tecnologico.
Cada um destes nıveis teve associado um grau de complexidade crescente e o objectivo de resolver
um problema especıfico.
Assim o nıvel conceptual, representa um estado ideal do problema, onde apenas existem objectos,
organizacoes e um numero reduzido de restricoes. As organizacoes percepcionam a totalidade do pro-
blema e conseguem resolver qualquer questao. Este nıvel foi utilizado para identificar as entidades, e
com estas, definiu-se um procedimento generico para resolucao do problema.
No nıvel logico definiram-se as interfaces das operacoes e algoritmos para a resolucao das tres
perguntas de rastreabilidade previamente definidas.
Finalmente no nıvel tecnologico instanciou-se o nıvel logico, num conjunto de tecnologias que per-
mitiram simular o problema, testando desta forma o comportamento esperado dos algoritmos.
Durante a concepcao dos algoritmos e devido a definicao das premissas de pesquisa identificaram-
se semelhancas entre as pesquisas de track e trace que levaram ao agrupamento de ambas num unico
problema. Conceptualmente uma pesquisa track pode ser implementada recorrendo ao ultimo estado
observado numa pesquisa trace daı estas pesquisas serem consideradas semelhantes nesta fase do tra-
balho apesar de terem utilizacoes e fundamentos distintos.
26
3.1.1 Nıvel Conceptual
O nıvel conceptual foi concebido para representar uma simplificacao do problema. Atraves desta
simplificacao foi possıvel identificar as entidades necessarias no processo de rastreabilidade, perguntas
que estas tem que responder de forma a ser possıvel rastrear um produto e por fim a informacao ne-
cessaria para resolucao das perguntas. Este nıvel sera utilizado para definir um universo simplista para
a caracterizacao da solucao. O primeiro passo na construcao do nıvel conceptual passa pela definicao
das entidades que constituem este universo.
3.1.1.1 Entidades
As entidades definidas sao os elementos basicos que constituem o universo simplificado do problema.
Estes elementos representam tanto objectos fısicos do universo como entidades abstractas. Assim sendo
identificaram-se tres tipos de entidades que compoem o sistema:
• Objectos
• Organizacoes
• Eventos
Os objectos representam todos os bens materiais, consumıveis ou constantes, que se movimen-
tam no sistema. No cenario utilizado, os objectos sao tanto os portateis, como os componentes que os
compoem, e os contentores que os movimentam. De forma a permitir a sua identificacao um objecto
devera ter associado um atributo que o identifique dos restantes.
As organizacoes sao entidades abstractas que visualizam e movimentam os objectos. As
organizacoes tem uma fronteira, fora da qual nao conseguem visualizar objectos. Tem informacao
sobre os objectos e comunicam com as restantes organizacoes para obter informacoes sobre objectos.
Adicionalmente ao contactarem com um objecto desconhecido, conseguem identificar a organizacao
proprietaria do mesmo, ou aquela que o criou.
Os eventos sao as entidades basicas de informacao, partilhadas entre organizacoes. Representam
uma interaccao com o objecto. Esta interaccao pode ser uma observacao, uma agregacao, movimentacao,
etc. A partir do conjunto total dos eventos associados a um objecto devera ser possıvel obter a resposta a
todas as perguntas de rastreabilidade. A tipologia do evento dara informacao sobre alteracoes ao estado
do objecto, se este foi movimentado, agregado, alterado ou destruıdo. A restante informacao do objecto
devera associar a esse evento uma caracterıstica de unicidade espacial e temporal.
Uma actividade que relaciona as tres entidades aqui definidas sera a observacao de um objecto
por parte de uma organizacao. Este exemplo define uma relacao hierarquica entre as tres entidades.
27
Figura 3.1: Entidades no nıvel conceptual
Organizacoes interagem com objectos. Da interaccao resulta um evento que regista a accao. O evento
por sua vez sera mantido pela organizacao que tera a responsabilidade de partilhar eventos com outras
organizacoes.
O evento tera entao associada a seguinte informacao:
• Lista de identificadores de objectos
• Tipo de evento
• Local
• Instante
A proxima figura( 3.1) descreve em pormenor as caracterısticas de cada uma das entidades identi-
ficadas.
3.1.2 Nıvel Logico
No nıvel logico serao definidos os metodos e interfaces de acesso as diversas entidades definidas. Estes
metodos serao disponibilizados pelas proprias entidades e serao os fundamentos para os algoritmos
apresentados no final desta seccao.
Recordando a estrutura hierarquica definida no modelo conceptual, existem neste momento
organizacoes que observam objectos, accao da qual resulta um evento.
Para que esta sucessao de acontecimentos seja possıvel, e necessario, em primeiro lugar, que a
organizacao tenha ao seu dispor formas de observar e identificar objectos (1,2). Apos esta observacao
e identificacao do objecto e necessario identificar, qual a organizacao que e responsavel pelo mesmo e
que por sua vez devera possuir os eventos associados ao objecto(3). Apos esta identificacao e necessario
obter a lista de eventos do objecto para analise e futura obtencao do estado final do objecto(4). Caso o
objecto seja composto e necessario repetir todo o processo para cada um dos componentes (5,6...)( 3.2).
A tabela 3.1 resume os metodos identificados com respectivos argumentos e resultados esperados.
28
Figura 3.2: Processo de identificacao de objectos e obtencao dos eventos associados
Metodo Argumentos Retorno DescricaogetId Objecto Identificador Obtem o Identificador associado com
um determinado objectogetResponsavel Identificador Organizacao Identifica qual a organizacao que
possui eventos de um determinado produtogetEventos Identificador Lista Eventos Retorna a lista de eventos associado com
um determinado produto
Tabela 3.1: Metodos definidos no nıvel logico com respectivos argumentos, retornos e descricao
3.1.2.1 Algoritmos
Uma vez definidos os metodos basicos do nıvel logico e necessario definir os algoritmos basicos de
resolucao de BOM e Track ou Trace.
3.1.2.1.1 Bill-of-materials O Bill-of-materials (BOM) de um produto refere-se, como ja foi referido, a
uma descricao pormenorizada dos componentes existentes num produto. Esta descricao pode ser repre-
sentada por uma estrutura em arvore, onde a raiz representa o produto e cada no da arvore representa
um componente. Componentes compostos terao nesta representacao um ou mais nos filhos.
A construcao desta arvore obriga a uma consulta dos diversos eventos de agregacao associados a
um objecto. E apos a agregacao de um objecto B num objecto A que o objecto A passa a ter na sua
constituicao o objecto B, alterando desta forma a sua BOM 3.3. Nesta figura e visıvel progresso da
construcao de um portatil e como os diversos eventos sao registados. A montagem do disco rıgido
29
no portatil (passagem de T0 a T1) gera um evento de agregacao (E1). De igual forma a montagem
das memorias no portatil (passagem de T2 a T3) gera um evento de agregacao. Sao estes eventos de
agregacao que fundamentam o funcionamento das pesquisas BOM. As accoes que estao na origem des-
tes eventos sao as actividades que alteram o estado e constituicao dos objectos.
Figura 3.3: Diagrama de eventos considerados para a realizacao de um BOM
Ao longo da vida de um produto este sera essencialmente alterado na fabrica que o produziu ou
noutras que o utilizem como materia prima. Desta forma o passo inicial para a construcao de uma BOM
sera identificar o fabricante ou produtor do produto em causa. Uma vez identificado o produtor, devera
ser pedida a lista de eventos de agregacao que tenham como produto pai o objecto em causa. A lista
de eventos obtida podera ser insuficiente para a resolucao de uma BOM completa caso o produto tenha
mais que um nıvel de componentes associado. Se um componente tiver na sua composicao diversos
outros componentes, estes componentes nao estarao listados na primeira pesquisa, sendo necessario
repetir a mesma, individualmente para cada um dos componentes.
O algoritmo de resolucao de BOM sera
1. Identificar o objecto
2. Identificar o fabricante do objecto
3. Obter do fabricante a lista de eventos associados ao objecto
4. Construir BOM do objecto
5. repetir passos 1 a 4 para cada um dos componentes do objecto
6. Agregar todos os BOM
A figura 3.4 demonstra esquema conceptual do algoritmo onde e possıvel observar o fluxo de
operacoes.
30
Figura 3.4: Esquema conceptual do algoritmo generico para resolucao de BOMs
A tabela 3.2 resume os metodos descritos na imagem anterior, mapeando os mesmos com os
metodos definidos no nıvel logico. Os metodos 1.3 (findObj) e 1.4(filter) nao foram mapeados por se
tratarem de metodos internos que pretendem demonstrar um passo intermedio no processamento,
que apesar de nao estar existente no algoritmo executado pelo cliente, e necessario realizar pelas
organizacoes que disponibilizam os dados.
3.1.2.1.2 Track e Trace As pesquisas Track e Trace de um produto referem-se a capacidade de localizar
um produto ao longo do espaco e do tempo, ignorando ou mantendo uma nocao de historico. Sendo
o Track uma simplificacao de um Trace em que apenas importa o estado final, o trabalho desenvolvido
considerara a resolucao de Trace por esta ser mais complexa. A realizacao de Track podera ser bastante
optimizada se em vez de se processarem todos os eventos, se processasse o ultimo evento registado.
Considerando a necessidade de historico e o registo de duas dimensoes, espaco e tempo, a estru-
tura ideal para representar o resultado de uma pesquisa Trace sera uma lista de pares espaco/tempo
ordenada cronologicamente.
A construcao desta lista obriga a uma consulta tanto dos eventos de agregacao como dos eventos de
observacao. Os eventos de observacao permitem manter o registo dos locais por onde um objecto pas-
31
Metodo Nıvel Logico Argumentos Retorno DescricaogetBOM getId Objecto BOM Metodo inicial da execucao de uma BOMgetFabricante getResponsavel Identificador Organizacao Identifica qual o fabricante do produtogetEventos getEventos Identificador Lista Eventos Retorna a lista de eventos associado
com um determinado produtogetBOM getId Componente BOM Invocacao da execucao de uma BOM
para cada um dos componentes garantidouma exploracao completa nos componentes
Tabela 3.2: Metodos definidos no nıvel logico com respectivos argumentos, retornos e descricao
sou e identificar o instante em que permaneceram nesse determinado local. Ja os eventos de agregacao
permitem identificar as alteracoes ao objecto, e se este foi colocado em contentores ou outros objec-
tos. No caso de se verificar este acontecimento, todos os eventos associados ao objecto contentor terao
que ser processados, pois devem constar nos resultados do Trace do objecto inicial 3.5. Nesta figura
e demonstrado o metodo utilizado para realizar um trace ao produto e a importancia do controlo dos
objectos contentores. Neste exemplo um portatil pronto para venda ao cliente (T1) e colocado num con-
tentor (T2), o que gera um evento de agregacao(E2). De forma a reconstruir o percurso realizado pelo
portatil, a informacao gerada pelas observacoes e insuficiente. Atraves destas apenas e possıvel identi-
ficar a posicao (T1,E1) como a localizacao final do portatil, quando este foi colocado numa caixa(T3) e
esta colocada num veıculo(T4). De forma a processar correctamente o percurso realizado pelo portatil e
necessario considerar as agregacoes (T1 a T2 e T3 a T4) e todas as observacoes existentes ate que ocorra
a desagregacao do objecto (T2 a T3).
Figura 3.5: Diagrama de eventos considerados para a realizacao de um Trace
Ao contrario do que acontece nos BOM, este tipo de alteracoes assim como o registo de observacoes,
esta distribuıdo ao longo de toda a cadeia de fornecimento, pelo que todas as organizacoes que intera-
gem com o objecto tem que ser contactadas.
O algoritmo de resolucao de Trace sera
1. Identificar o objecto
32
2. Identificar as organizacoes que interagiram com o objecto
3. Obter de cada organizacao a lista de eventos associados ao objecto
4. Construir o Trace do objecto
5. repetir passos 1 a 4 para cada um dos contentores onde o objecto foi inserido
6. Agregar todos os Trace
A figura 3.6 demonstra esquema conceptual do algoritmo onde e possıvel observar o fluxo de
operacoes.
Figura 3.6: Esquema conceptual do algoritmo generico para resolucao de Traces
A tabela 3.3 resume os metodos descritos na imagem anterior, mapeando os mesmos com os
metodos definidos no nıvel logico. Os metodos 1.3 (obterEventos) e 1.4(filtrar) nao foram mapeados por
se tratarem de metodos internos que pretendem demonstrar um passo intermedio no processamento,
que apesar de nao estar existente no algoritmo e necessario realizar.
33
Metodo Nıvel Logico Argumentos Retorno DescricaogetTrace getId Objecto Trace Metodo inicial da execucao de um TracegetHandlers getResponsavel Identificador Organizacao Identifica quais as organizacoes
que interagiram com o produtogetEventos getEventos Identificador Lista Eventos Retorna a lista de eventos associado
com um determinado produtogetTrace getId Contentor Trace Invocacao da execucao de um Trace
para cada um dos contentores garantidouma exploracao completa nos
movimentos do objecto
Tabela 3.3: Mapeamento dos metodos de resolucao de Trace com os metodos definidos no nıvel logico
Neste momento e possıvel concluir que a execucao tanto de BOM como de Trace e muito semelhante.
O algoritmo na sua forma conceptual e identico, apenas variando em dois pontos:
• A identificacao das organizacoes onde se realizam as pesquisas;
• A filtragem aplicada nos eventos retornados.
Enquanto o BOM e realizado ao nıvel dos fabricantes, sendo processado apenas uma organizacao
por componente, no caso de um Trace e processada a totalidade do universo de organizacoes que in-
teragiram com o componente. Nos filtros os dois algoritmos seguem abordagens diferentes. Enquanto
o BOM considera agregacoes em que cada componente esteja num nıvel inferior ao anterior, o Trace
considera tanto observacoes como agregacoes em que cada componente esteja num nıvel superior ao
anterior, o que acontece nos caso dos contentores.
3.1.3 Nıvel tecnologico
A ultima fase na definicao da arquitectura passa por um mapeamento do nıvel logico para o nıvel tec-
nologico, onde sera escolhido um conjunto de tecnologias e componentes para implementar os elemen-
tos e respectivas funcionalidades anteriormente identificadas.
Ao definir-se o nıvel conceptual foi definido um conjunto de entidades,entidades estas utilizadas
para representar o universo do problema. Agora e necessario seleccionar as tecnologias que implemen-
tam essas entidades, representando-as num contexto aplicacional.
A primeira entidade definida foi o objecto. Este teria que disponibilizar um conjunto de metodos
que permitissem identifica-lo e obter informacao basica sobre o estado deste. A identificacao de objectos
sera realizada recorrendo a etiquetas rfid, que entre outras informacoes, disponibilizam um identificador
unico universal atraves dos codigos EPC. De forma a permitir um futuro processamento dos dados,
34
Nıvel Conceptual Evento EPCIS Observacao EPCIS Agregacao EPCISTipo Evento action(Observe) Obrigatorio -
action(Add) - Obrigatorioaction(Delete) - Obrigatorio
Objectos epcList Obrigatorio -parentId - ObrigatoriochildEPC - Obrigatorio
Local bizLocation Obrigatorio ObrigatorioTempo eventTime Obrigatorio Obrigatorio
Tabela 3.4: Mapeamento dos atributos do evento conceptual com os atributos dos eventos EPCIS
todos os codigos EPC definidos deverao estar organizados de forma hierarquica. Os codigos EPC sao
utilizados para identificacao nao so de objectos, mas tambem de localizacoes, leitores, processos de
negocio, etc. No cado de localizacoes, estas serao representadas por todos os espacos ate a fronteira
da organizacao. Ou seja uma prateleira existente num armazem da empresa A, sera representada por
exemplo por A:ArmazemB:Prateleira22. Desta forma identifica-se unicamente o local, quer dentro da
organizacao, quer fora desta.
A segunda entidade definida foi a organizacao. Esta entidade sera uma entidade abstracta, sendo
representada por um conjunto de modulos/elementos na arquitectura. Uma organizacao sera desta
forma uma entidade legal, delimitada por uma fronteira, fora da qual nao tem qualquer tipo de auto-
ridade. Cada organizacao sera entao definida pela informacao que possui, pelos objectos que controla
num determinado instante, e ainda pelas aplicacoes ou modulos que possui na sua arquitectura.
Finalmente, a terceira entidade definida foi o evento. Os eventos, tal como foram definidos, pode-
riam ser de diversas tipologias, registariam tanto o tempo como o espaco do acontecimento e ainda uma
lista de identificadores de objectos associados. Esta entidade sera representada recorrendo aos eventos
EPCIS. A tabela 3.4 especıfica cada um dos atributos do evento conceptual e identifica o atributo do
evento EPCIS utilizado para o mapeamento. A tabela foi construıda com base na avaliacao que Frederic
Thiesse e Florian Michahelles realizaram sobre aplicacoes de sistemas RFID e a informacao registada em
eventos EPCIS [28].
Os atributos bizLocation, bizStep, disposition, bizTransactionList nao foram considerados por nao
interferirem com os processos de rastreabilidade. Assim sendo sao atributos opcionais nos processos de
captura de informacao.
Uma vez que se recorrem aos eventos EPCIS para realizar o mapeamento com os eventos do nıvel
conceptual, fara sentido recorrer a outros elementos do standard EPCIS para definir outros componentes
identificados.
A Query Interface do Standard EPCIS e a forma ideal para realizar as perguntas sobre os eventos
35
EPCIS, que cada organizacao possui. Desta forma os metodos getEventos identificados no nıvel logico,
serao implementados recorrendo ao metodo poll da Query Interface.
Findo este mapeamento inicial, serao propostas duas arquitecturas alternativas para a
implementacao da rfrbNet. As arquitecturas serao comparadas funcionalmente e validadas contra os
objectivos definidos no capıtulo introdutorio. No final desta comparacao sera seleccionada a arquitec-
tura a utilizar no resto do trabalho.
3.1.3.1 EPCIS + ERP
A primeira arquitectura definida recorre a uma metodologia process and forward para resolucao das per-
guntas de rastreabilidade. Esta metodologia e semelhante aos processos Middleware Multitier [29] onde
os participantes sao organizados hierarquicamente e cada um deles apenas conhece o elemento superior
e o inferior. Segundo esta organizacao a loja e a fabrica inicial ficam localizadas em extremos opostos da
cadeia. Cada elemento desta, identifica o proximo elemento da cadeia.
Nesta implementacao, nao foram definidos servicos comuns para a federacao. Cada participante
da rede, tera dois componentes base responsaveis pela execucao de todas as pesquisas. O primeiro
e um repositorio EPCIS onde todos os eventos sao registados e mantidos para futuras pesquisas. O
segundo elemento e um ERP -Enterprise Resource Planning que tem como funcao, identificar a fonte e o
destino de cada objecto registado pelo EPCIS. Este elemento ira implementar os metodos getHandlers e
getFabricantes. Para resolver estas perguntas o ERP verifica nos seus registos se a entidade proprietaria
do objecto existe no sistema. Caso nao exista, o ERP contactara a origem do produto, e atraves desta
seguira todos os elementos existentes na cadeia de distribuicao ate identificar o produtor do objecto.
Uma vez identificado o produtor, a pergunta getEventos e dirigida directamente ao repositorio EPCIS.
A implementacao desta arquitectura apresenta-se descrita na figura 3.7. Nesta figura e possıvel
observar a execucao o exemplo de uma pesquisa. A aplicacao cliente, responsavel por executar todas
as pesquisas de rastreabilidade, inicia a pesquisa no repositorio EPCIS local da sua organizacao (1). De
seguida contacta o ERP (2) da sua organizacao para identificar a fonte do objecto (Participante2) onde
ira realizar nova pesquisa no repositorio (3). Na analise dos documento surge um novo objecto de in-
teresse para o qual e necessario repetir as perguntas realizadas. O ERP local e contactado novamente
para obter informacao (4), sendo este um objecto desconhecido, e reencaminhado o pedido para o ERP
da organizacao que disponibilizou os dados (5). Este ERP identifica a organizacao proprietaria (Partici-
pante4) que sera contactada (6) repetindo-se todos os contactos caso surjam dados de interesse(7).
36
Figura 3.7: Arquitectura EPCIS + ERP
3.1.3.2 EPCIS + Discovery Services
A segunda arquitectura definida recorre a Discovery Services para resolucao da perguntas de rastreabi-
lidade. Considerou-se que os Discovery Services seriam servicos controlados pela federacao, garantido
desta forma uma correcta implementacao dos mesmos, e que estes defendiam os interesses globais da
federacao. Os Discovery Services, entre outras capacidades, possuem metodos para registo de percurso
realizado por cada objecto, sendo desta forma possıvel identificar o conjunto de organizacoes que pos-
suem informacao sobre os mesmos. A resolucao das pesquisas seguem um modelo semelhante a uma
arquitectura Peer-to-peer uma vez que cada elemento serve como servidor de informacao, partilhando e
disponibilizando os seus recursos, integrado numa rede de parceiros, que acedem directamente os re-
cursos partilhados [30]. Nesta arquitectura cada participante da rede, tera apenas um componente sobre
a sua responsabilidade. Este sera o repositorio EPCIS onde todos os eventos sao registados e mantidos.
Similarmente com a arquitectura anterior, os Discovery Services implementam os metodos getHan-
dlers e getFabricantes. Ao contrario da arquitectura anterior esta pesquisa sera realizada num unico
local, que possuira a totalidade da informacao minimizando as pesquisas para identificacao das
organizacoes de interesse. Por outro lado apresenta uma fragilidade ao necessitar que cada partici-
pante participe activamente, na actualizacao dos Discovery Services, disponibilizando informacao sobre
37
os objectos que observa.
A implementacao desta arquitectura apresenta-se descrita na figura 3.8.
Figura 3.8: Arquitectura EPCIS + Discovery Services
Nesta figura e possıvel observar um exemplo de uma pesquisa. A aplicacao cliente, responsavel
por executar todas as pesquisas de rastreabilidade, inicia todas as pesquisar nos discovery services onde
identifica as organizacoes que possuem os dados(1,3,5). Apos este passo inicial, contacta directamente
o repositorio EPCIS de cada organizacao.
Com esta alteracao no processamento inicial, a aplicacao cliente perde a ligacao que tem com os
servicos locais, podendo actuar como uma entidade singular na arquitectura, uma vez que os Discovery
Services sao comuns a todos os participantes.
3.1.3.3 Comparacao Arquitecturas
As arquitecturas apresentadas diferem nao so na implementacao dos algoritmos definidos, mas tambem
ao nıvel funcional. A primeira arquitectura funciona segundo um conceito centrado no participante,
onde cada elemento define e gere localmente a informacao. A segunda arquitectura esta mais proxima
de um conceito de federacao, onde existem servicos disponibilizados e controlados por terceiros, que
tem como responsabilidade garantir um correcto funcionamento do sistema e igualdade de direitos e
obrigacoes entre os participantes.
No capıtulo introdutorio foram definidos um conjunto de objectivos e caracterısticas que a arqui-
tectura final devera possuir. A tabela 3.5 apresenta esses mesmos objectivos reorganizados segundo
38
Id Requisito EPCIS + ERP EPCIS + Discovery ServicesFuncional
1 Permitir a partilha de informacao entre parceiros Sim Sim2 O fluxo de mensagens simular o fluxo
do produto na cadeia de fornecimento Sim Sim3 Mitigar utilizacoes abusivas do sistema Nao Nao4 Permitir definir diferentes nıveis de pesquisa Nao Nao5 Replicar alteracoes nas cadeias, em
alteracoes nos acessos aos dados Nao Nao6 Aceder informacao nos sistemas de
cada entidade em vez de copias locais Sim Sim7 Suportar uma linguagem de negocio para
definir permissoes de acesso e diferentesnıveis de detalhe na informacao Nao Nao
8 Ser capaz de processar grandesquantidades de dados Sim Sim
Tecnico9 Uniformizacao da informacao Sim Sim10 Definicao de primitivas para
perguntas de rastreabilidade Sim Sim11 Definicao de algoritmos de pesquisa Sim Sim12 Definir sistemas de autenticacao e autorizacao Nao Nao13 Garantir a escalabilidade do sistema N.A. N.A.14 Manter-se operacional mesmo que existam
falhas num dos elementos Nao Sim15 Definir e alterar permissoes de acesso Nao Nao
Tabela 3.5: Comparacao das arquitecturas apresentadas segundo os objectivos definidos inicialmente
requisitos tecnicos ou conceptuais e compara as duas arquitecturas identificando os requisitos que cum-
pre.
As duas arquitecturas apresentadas sao bastante semelhantes nos requisitos que cumprem funci-
onal e tecnicamente. Esta similaridade resulta do processo inicial que foi seguido, na definicao das
entidades, algoritmos e principais escolhas tecnologicas. Este processo teve um impacto nos requisitos
tecnicos (9,10,11). Ambas as arquitecturas permitem uma partilha de informacao atraves de acessos
directos ao repositorios de dados, cumprindo os requisitos 1 e 6.
O requisito funcional 2 e cumprido nas duas arquitecturas de formas distintas. Na arquitectura EP-
CIS + ERP o fluxo de mensagens segue o fluxo do objecto uma vez que o proximo elemento a contactar
em cada iteracao sera a organizacao destino do produto, obtida directamente do ERP do elemento ac-
tual. Na arquitectura baseada em Discovey Services o fluxo das mensagens e determinado pelo Discovery
Services que pode retornar a lista ordenada por data de observacao do produto.
O ultimo requisito funcional verificado em ambas as arquitecturas e o requisito 8 referente a capa-
cidade de processamento de grandes volumes de dados. Tendo ambas as arquitecturas a informacao
39
segmentada por diversos repositorios, o volume de dados a processar esta dependente exclusivamente
da informacao gerada para fins de rastreabilidade. Ou seja a quantidade de informacao a processar, nao
depende do numero de elementos existentes da rede, mas antes da estrutura da propria cadeia.
A grande diferenca entre as arquitecturas encontra-se no requisito 14, que indica que as redes de-
vem manter-se funcionais caso um elemento falhe. Na primeira arquitectura, caso um elemento falhe,
a realizacao das perguntas de rastreabilidade falhara. Nesta arquitectura cada elemento da rede dispo-
nibiliza o maximo de informacao sobre um objecto antes de indicar qual o proximo elemento da rede
a contactar. Caso um dos elementos na cadeia falhe, sera impossıvel reconstruir o restante caminho da
cadeia. Este problema poderia ser resolvido recorrendo a tecnicas de disseminacao da informacao pelos
ERP dos participantes. A aplicacao destas tecnicas teria um impacto muito grande neste elemento que
passaria a gerir grandes volumes de informacao o que seria impraticavel na execucao de pesquisas e
aumentaria consideravelmente o custo da rede.
O requisito 13 nao foi avaliado devido a falta de dados e a consequente incapacidade de simular
diversos cenarios.
Adicionalmente a estes requisitos, existe um conjunto de requisitos (3,4,5,7,12 e 15) que ainda nao
sao cumpridos por ambas as arquitecturas. Estes requisitos sao tanto tecnicos como funcionais e dizem
respeito, na sua maioria, a um controlo da informacao partilhada que ainda nao foi abordado neste
trabalho. Sendo este um sistema que se pretende aplicar em diversas cadeias de fornecimento, e ne-
cessario garantir uma harmonia entre todos os participantes e que organizacoes com sentimentos de
concorrencia possam co-habitar no mesmo sistema.
Os requisitos adicionais suportados pela arquitectura federada assim como os benefıcios que se
obtem pela gestao centralizada levam a que a segunda arquitectura seja a arquitectura eleita para a
execucao do resto do trabalho.
3.2 Pol��ticas
Ate este momento, foram definidas duas arquitecturas que cumprem os requisitos mınimos funcio-
nais de um sistema de rastreabilidade. Actualmente e possıvel obter o estado de objectos, o percurso
efectuado e ainda a sua composicao em sub-componentes. As funcionalidades disponibilizadas pela
arquitectura actual, apesar de serem fundamentais para a operacionalidade do sistema, nao garantem
a totalidade da funcionalidades de um sistema do genero. Para tal e necessario garantir que diferentes
entidades, com interesses distintos sobre os objectos, possam colaborar no sistema. Esta necessidade
advem da propria estrutura da federacao, uma vez que numa federacao so, poderao co-habitar distintas
redes de fornecimento. Estas redes podem concorrer sobre a distribuicao de um determinado produto,
quer entre redes, quer internamente 3.9.
40
Figura 3.9: Exemplo de concorrencia nas redes de distribuicao
De forma a garantir uma estabilidade funcional da rede e necessario estabelecer diferentes tipos de
acesso as redes. Considerando dois fabricantes de uma mesma tipologia de produto, que concorrem pelo
fabrico e venda da mesma, sera facil admitir que estes, nao pretendam colaborar mutuamente. Desta
forma devem minimizar a informacao partilhada entre eles, pelo menos, sobre o produto em causa.
Para solucionar este problema e necessario considerar algumas funcionalidades adicionais inexis-
tentes na solucao actual, sejam estas:
• Definir metodos de identificacao e autorizacao de entidades;
• Definir metodos de filtragem de informacao.
O primeiro passo devera disponibilizar formas de identificar quem e quem na rede. A cada partici-
pante devera estar associada uma unica identificacao, quais as redes de distribuicao em que participa e
finalmente qual o seu papel em cada rede de distribuicao. Este passo diz respeito aos requisitos funcio-
nais de seguranca.
Apos este passo sao definidos os requisitos nao funcionais de seguranca, onde se determinam os
processos para adequar o detalhe de informacao obtido em cada consulta ao estado interno da rede de
distribuicao. Estes metodos foram definidos recorrendo as nocoes de polıticas e regras de negocio de
Maryann Hondo [31].
3.2.1 Identificacao e autorizacao de entidades
Conforme foi referido na seccao anterior, para que a rede federada se torne funcional e necessario dis-
ponibilizar metodos de identificacao e autorizacao de entidades. Pretende-se nesta seccao resolver a
41
identificacao de parceiros e de redes de distribuicao de forma a garantir que nao existem falsas entida-
des e que os dados circulam apenas dentro das respectivas redes de distribuicao. Uma vez que estes
problemas (identificacao e autorizacao) estao bastante estudados pretende-se definir para a federacao
um conjunto de funcionalidades a implementar e identificar quais as responsabilidades de cada ele-
mento.
A identificacao de entidades na federacao surge da necessidade de identificar inequivocamente
cada entidade participante, de forma a garantir que nenhuma entidade consegue aceder a dados que so
estao disponıveis a terceiros. Sendo esta funcionalidade de caracterısticas extremamente sensıveis para
todas as entidades, devera ser implementada e controlada pela federacao de forma a garantir um uso
e manutencao correctos. Ao colocar-se este controlo na federacao, garante-se que a gestao e feita por
uma entidade independente e que prevalece sempre o benefıcio mutuo em detrimento do benefıcio ou
aproveitamento individual.
A implementacao tecnologica, passa por um servico de autenticacao centralizado e cifra de men-
sagens recorrendo a certificados. Esta escolha mantem validos os princıpios da arquitectura EPCIS, em
que os metodos de autenticacao definidos para os repositorios nao sao abordados pelo standard, que
delega tal responsabilidade para a implementacao dos repositorios. Cada entidade participante nao de-
vera tomar parte activa no processo de identificacao, alem das fases obrigatorias de autenticacao perante
a federacao antes de realizar qualquer consulta na rede.
Uma vez que para obter informacao sobre o percurso dos objectos e necessario contactar o Disco-
very Services da federacao garante-se que sem estarem autenticados nao conseguem reconstruir o per-
curso do objecto e desta forma nao e possıvel realizar as pesquisas de rastreabilidade. Finalmente para
vedar o acesso a dados a entidades nao autenticadas, basta recorrer aos certificados referidos anterior-
mente, que deverao ser validados em cada pedido, contra os servicos de autenticacao da federacao. Esta
implementacao recai sobre a responsabilidade individual de cada participante, que devera configurar
os seus repositorios para utilizar os servicos de autenticacao da federacao para validar as credenciais de
cada requerente de informacao.
A gestao de entidades pela federacao devera ser o mais agil possıvel. Sabendo que numa mesma
federacao podem co-habitar diferentes redes de distribuicao, cada uma delas com um elevado numero
de participantes e que cada participante pode participar em diversas redes de distribuicao, rapidamente
se concluı que uma gestao individual de credenciais e impraticavel. E necessario resolver para cada par
de entidades, quais os grupos em que pertencem e sobre qual rede estao a obter dados. Para facilitar esta
gestao e necessario agrupar a informacao, simplificar a representacao da cadeia e definir genericamente
para cada entidade as suas relacoes com as restantes.
Para resolver este problema as redes e participantes foram organizados segundo as nocoes de gru-
pos e roles.
42
Um grupo engloba um conjunto de entidades que interagem entre si com vista a um benefıcio
mutuo, neste caso a rede de distribuicao. A informacao devera circular unicamente dentro do grupo
e nunca para fora deste. Caso uma entidade participe em mais que um grupo, esta devera pertencer
aos diversos grupos (Figura 3.10). Os Discovery Services devem ter a capacidade de identificar a que
grupo pertence um determinado produto. Durante a execucao das pesquisas de rastreabilidade esta
capacidade dos Discovery Services ira garantir que a informacao de um grupo nao e partilhada para
outros grupos atraves de nos em comum.
Figura 3.10: Simplificacao obtida nas redes de distribuicao pela utilizacao de grupos
No caso do cenario existe um unico grupo, uma vez que so esta representada uma rede de
distribuicao.
O role identifica diferentes papeis ou posicoes que uma entidade pode adquirir dentro de uma rede
de distribuicao. Para esta divisao foi seguida uma abordagem funcional de cada elemento, devendo
uma entidade pertencer a um dos seguintes papeis:
• Produtor
• Distribuidor
• Loja
• Manutencao
Outros papeis poderiam existir para representar elementos dentro de uma rede, como por exem-
plo auditor, mas tais nao foram considerados uma vez que nao possuem parte activa na questao da
rastreabilidade de produtos. O recurso a esta nocao simplifica a gestao das autorizacoes uma vez que
cada elemento da rede define as autorizacoes de partilha para um numero mais reduzido de elementos
(Figura 3.11).
No caso do cenario de teste, estao representados tres roles. O role de produtor atraves dos elementos
Barebones e Laptops, o role de distribuidor atraves dos dois centros de distribuicao e finalmente o role
Loja atraves do elemento store.
43
Figura 3.11: Simplificacao obtida nas redes de distribuicao pela utilizacao de roles
O recurso as nocoes de grupos e roles, juntamente com a utilizacao de certificados e com os servicos
de autenticacao centralizados na federacao, permite uma identificacao unıvoca de cada participante.
Este e organizado e categorizado segundo as redes em que participa e pelas funcoes que desempenha
em cada uma destas.
Uma vez resolvida a identificacao de entidades e necessario definir metodologias de autorizacao e
filtragem de informacao.
3.2.2 Polıticas de partilha de informacao
Com os metodos de identificacao de entidades definidos, a federacao ficou dotada de metodos que per-
mitem identificar cada organizacao e simplificou-se a gestao de entidades atraves de uma reorganizacao
em grupos e roles. Agora e necessario identificar quais entidades estao autorizadas a aceder a uma
informacao especıfica.
Analisando o comportamento de uma rede de distribuicao, e frequente que duas organizacoes com-
pitam sobre um mesmo recurso hoje, mas amanha tenham que colaborar na producao de um outro
produto. Esta situacao e facilmente comprovada atraves do cenario criado para este trabalho e repre-
sentado na figura 3.9. Observando os dois centros de distribuicao, ambos participam na mesma rede
de distribuicao mas em momentos distintos. O centro de distribuicao que transporta os produtos da
fabrica de portateis ate a loja final, nao devera ter o mesmo acesso a informacao que o primeiro centro
de distribuicao. Este apenas devera visualizar a informacao, apos a sua interaccao com os produtos.
Desta forma as diversas autoridades devem usufruir de metodos de autorizacao dinamicos, de forma a
replicar a propria dinamica da rede.
Estes metodos de autorizacao dinamicos serao implementados recorrendo a nocao de polıticas de
partilha. A IBM classifica as polıticas como sendo uma demonstracao de intencao ou orientacao [31],
existindo tres tipos de polıticas: negocio, arquitecturais ou operacionais.
Considerando o cenario deste trabalho uma polıtica de negocio definida por uma organizacao, seria
44
algo como: Nao partilho informacao com os meus competidores. A polıtica arquitectural seria: Nao par-
tilho informacao com organizacoes que nao interagiram com os meus produtos ou que nao participarao
na cadeia de distribuicao destes. Finalmente a polıtica operacional seria: Organizacoes que colaborem
na minha rede, devem saber os quando desloquei os objectos, com um nıvel de detalhe ao minuto. Neste
trabalho consideraremos polıticas operacionais, que devem estar estruturadas da seguinte forma:
1. Partilha para elementos externos a federacao
2. Partilha para elementos de grupos em que nao participa
3. Partilha para elementos de grupos em que participa
Partilha para cada tipo de role presente no grupo
4. Partilha para elementos especıficos
Foi seleccionada esta estrutura, de forma a definir uma hierarquia no acesso a informacao. No topo,
estao presentes os elementos cujo acesso deve ser mais restrito, e a medida que se desce, aumenta o nıvel
de detalhe da informacao retornada.
De forma a minimizar a definicao de polıticas ponto a ponto, as organizacoes devem avaliar os
restantes parceiros da rede, no grupo de elementos em que participa, para existir uma reutilizacao das
regras para diversos elementos, e desta forma reduzir consideravelmente a dimensao das polıticas a
aplicar.
A definicao de partilha com elementos especıficos devera ser utilizado em situacoes excepcionais,
em que os elementos envolvidos, possuem relacoes fortes de negocios, colaborando em mais do que
uma rede.
O acordo de polıticas entre duas entidades, passa desta forma a ser um passo adicional a executar
antes da execucao das pesquisas de rastreabilidade 3.12. Durante a execucao das pesquisas devera ser
obtida a polıtica em vigor dos repositorios da federacao. Em qualquer altura um parceiro pode alterar a
sua polıtica, bastando para tal enviar a nova polıtica para a federacao.
Figura 3.12: Processo de acordo de polıticas
45
Elemento Original Nıvel 1 Nıvel 3Espaco A:CidadeA:ArmazemB:Prateleira22 A:CidadeA:ArmazemB ATempo 2011-01-15 09:31:15 2011-01-15 09:31:00 2011-01-15
Tabela 3.6: Resultados obtidos pela aplicacao dos diversos nıveis de detalhe
As polıticas definidas alem de definir as organizacoes com quem uma determinada organizacao
esta disposta a partilhar informacao, devera definir o nıvel de detalhe da informacao partilhada. E esta
definicao que permite distinguir os dados que cada organizacao tem acesso. De forma a realizar esta
distincao, sera utilizada a nocao de regras [31]. As regras sao uma implementacao de uma polıtica,
neste caso de partilha de informacao. Neste caso as regras sao regras de decisao determinısticas [31].
Consideram-se regras de decisao, uma vez que o resultado das regras (decisao) e calculado com base
num conjunto de informacao. A informacao que alimenta este calculos e composta pelos grupos e papeis
desempenhados por cada uma das organizacoes.
Uma mesma polıtica sera composta por diferentes regras cada uma com um nıvel de detalhe asso-
ciado. Esse nıvel de detalhe e definido individualmente para cada elemento de informacao. O nıvel de
detalhe definido representa o nıvel de detalhe maximo da partilha.
Os elementos de informacao sobre os quais sao definidos os nıveis de detalhe, sao os mesmos que
foram definidos no nıvel conceptual:
• Espaco
• Tempo
• Tipologia de Evento
• Tipologia de Objecto
Os nıveis de detalhe associados a cada um dos elementos de informacao deverao permitir que a
informacao retornada em cada pedido seja adaptada consoante a organizacao requerente.
Durante a definicao do nıvel tecnologico, recorreu-se a codigos EPC hierarquicos para proceder
a identificacao de locais e objectos. A estrutura hierarquica de identificacao, permite recorrer a indi-
cadores numericos para a definicao de nıveis de detalhe no acesso a informacao. Quanto maior for o
indicador do nıvel de detalhe, maior sera o filtro aplicado na informacao, o que resultara num detalhe
inferior. A tabela 3.6 demonstra dois exemplos do nıvel de detalhe obtido, atraves desta classificacao da
informacao.
A figura 3.13 demonstra o resultado obtido pela aplicacao das polıticas nos resultados das pesquisas
de rastreabilidade.
46
Figura 3.13: Aplicacao das polıticas aos resultados das pesquisas
Apos esta definicao de nıveis de detalhe de informacao, e necessario definir na arquitectura, quais
serao os locais de filtragem dos dados partilhados. A escolha do local teve em consideracao dois factores
principais:
• A filtragem da informacao deve ser controlada pela federacao;
• Os repositorios podem nao ser de uso exclusivo para a federacao.
A filtragem da informacao deve ser controlada pela federacao, pois so esta entidade pode garantir
uma correcta aplicacao das polıticas e regras, definidas e acordadas por dois parceiros.
Os repositorios sao estruturas complexas que albergam grandes quantidades de dados. De forma a
reduzir custos, uma organizacao podera reutilizar estes para diferentes processos, mantendo uma unica
fonte de informacao. Assim sendo os filtros devem ser um modulo independente dos repositorios o
que garante a independencia e reutilizacao dos ultimos. Este modulo devera apresentar um comporta-
mento semelhante a um servico de proxy dos repositorios, implementando a interface EPCIS, de forma
a garantir um respeito pelos standards utilizados.
Cada vez que for contactado o filtro devera, apos autenticacao do cliente, obter a polıtica em vigor
a partir da federacao, contactar o repositorio obtendo dados, avaliar a polıtica e finalmente filtrar os
dados obtidos antes de os devolver ao cliente.
A avaliacao da polıtica pelo servico de proxy sera feita recorrendo a um motor de inferencias, que e
alimentado pela polıtica em vigor, identificacao do cliente e da entidade destinataria, tanto ao nıvel de
grupo como papel.
O recurso a servicos de proxy para os servidores, garante um correcto funcionamento dos algorit-
mos previamente definidos, bastando para tal que o Discovery Service retorne o endereco do proxy em
vez do endereco directo do repositorio.
A figura 3.2.2 apresenta a estrutura final da federacao, onde estao representados todos os compo-
nentes existentes nesta, identificando-se quais sao controlados individualmente ou pela federacao.
47
Figura 3.14: Arquitectura final da federacao
Com os novos componentes definidos foi possıvel dotar a arquitectura inicial com mecanismos que
permitem cumprir os requisitos funcionais inicialmente definidos.
48
4Implementa�c~ao
Apos a definicao de uma arquitectura e necessario validar o correcto funcionamento da mesma. Para
tal iniciou-se a implementacao dos componentes necessarios para testar o correcto funcionamento. A
implementacao dividiu-se em duas fase, uma inicial onde se implementou um emulador de cadeias de
distribuicao, e uma final onde a rede de distribuicao do cenario utilizado neste trabalho, foi instanciada
nos diversos componentes da arquitectura.
Numa fase inicial do trabalho o objectivo foi criar um sistema integrado, em que a fase de simulacao
e a fase de execucao das pesquisas de rastreabilidade poderiam ocorrer em simultaneo. Este objectivo
acabou por nao ser atingido devido a uma impossibilidade tecnica de executar o simulador em pleno.
Esta impossibilidade deveu-se a incapacidade de processamento do servidor aplicacional e respectivos
modulos do emulador o que levava a um funcionamento instavel com perda de deteccoes de objectos.
Apesar do insucesso na implementacao do emulador, o trabalho desenvolvido foi inovador na abor-
dagem ao tema da emulacao, pelo que se resumiu este num paper apresentado num workshop da es-
pecialidade. Um resumo do paper e da abordagem seguida na construcao do emulador e apresentado
na seccao que se segue neste capıtulo. A alternativa para solucionar a falta do simulador passou pela
separacao dos processos de recolha de informacao (emulador) e processamento desta (federacao).
Na parte final deste capıtulo serao descritos os modulos implementados, as respectivas tecnologias
e ainda as polıticas de partilha e respectiva estrutura.
4.1 Emulador de sistemas r�d
A inexistencia de dados de sistemas reais de rastreabilidade levou a que se decidisse construir um simu-
lador de cadeias de distribuicao. Este simulador teria como objectivo alimentar os repositorios EPCIS
do cenario criado para este trabalho. Durante a fase de desenho funcional do simulador, decidiu-se ino-
var na construcao do mesmo, e tentar disponibilizar um emulador completo dos sistemas rfid, em que
todos os componentes da arquitectura EPCGlobal estivessem presentes. Assim sendo foram definidos
os seguintes requisitos funcionais para o emulador:
1. Manipular objectos em vez de etiquetas e leitores;
Interaccao com objectoscreateObject cria um objecto na posicao indicadamoveObject move um objecto para uma determinada posicaogroup insere um objecto dentro de outroungroup retira um objecto do interior de outroInteraccao com elementos rfidcreateTag indica que um objecto tem uma etiqueta de um determinado tipocreateReader indica que um objecto e um leitor
Tabela 4.1: Operacoes definidas para interagir com o simulador
2. Criar elementos RFID sem ser necessario conhecimento tecnico ao nıvel de configuracoes;
3. Manter a nocao de agregacao, contentor, e objecto;
4. Permitir definir os dados das etiquetas;
5. Disponibilizar um metodo para replicar simulacoes.
Pretendeu-se com estes requisitos, construir um emulador onde estivessem presentes todos os con-
ceitos e accoes da tecnologia rfid, mas que estes fossem uma reaccao da interaccao com objectos, por
parte do utilizador. Assim o utilizador deveria interagir com os objectos presentes na sua realidade
(objectos e contentores), e observar o impacto resultante dessas interaccoes, nos sistemas rfid.
Para tal foi definido um conjunto de actividades, com as quais um utilizador pode criar, mover,
agrupar de desagrupar objectos (tabela 4.1.
As operacoes definidas foram organizadas segundo tres nıveis logicos (Imagem 4.1).
Com as operacoes definidas um utilizador tinha ao seu dispor, todos os metodos necessarios para
emular a cadeia de fornecimento. De forma a iniciar a simulacao, o utilizador teria que criar um con-
junto de objectos (createObject) e definir para cada um deles se seria uma etiqueta (createTag) ou um
leitor(createReader). As etiquetas dos objectos seriam de um determinado tipo, o que permitia distin-
guir entre objectos e contentores. Os leitores teriam uma posicao e um alcance de leitura. Todas as
etiquetas existentes na area de alcance do leitor seriam detectadas por estes, o que iniciaria uma captura
para os restantes elementos da arquitectura.
A arquitectura tecnologica do emulador replica funcionalmente uma solucao completa de rastre-
abilidade, composta por todos os elementos deste os leitores ate aos repositorios, passando pelo mid-
dleware de comunicacao com os leitores e as aplicacoes de captura que filtram e alimentam os repo-
sitorios. A arquitectura do simulador, assim como os diversos elementos tecnologicos utilizados na sua
implementacao estao apresentados na figura 4.1 e descritos na tabela 4.1. Os elementos com fundo a
50
Figura 4.1: Arquitectura logica do simulador
azul foram desenvolvidos para o simulador, sendo que os elementos com fundo cinza, foram elementos
utilizados de outros projectos 1 2.
Os elementos do projecto Rifidi, estao presentes na camada OSGI da arquitecura. Estes elementos
foram responsaveis pela criacao de leitores e por disponibilizar uma linguagem de scripts para controlo
dos mesmos.
Os elementos do projecto Fosstrak, corriam num servidor Apache Tomcat 3e eram compostos pelo
repositorio ECPIS e por um servidor para processamento de eventos ALE emitidos pelos leitores. Este
ultimo componente tinha como principal funcao recolher todos os eventos de deteccao emitidos pe-
los leitores, aplicar-lhes um filtro de forma a eliminar ruıdos nas deteccoes, assim como deteccoes du-
plicadas, e finalmente reencaminhar os eventos filtrados para a aplicacao de captura respectiva. Esta
aplicacao de captura, filtrava novamente os eventos e inseria os mesmos no repositorio EPCIS.
Com esta arquitectura seria possıvel uma emulacao de um sistema completo rfid, sem ser necessario
adquirir hardware especıfico, e estaria acessıvel a pessoas sem conhecimentos profundos dos sistemas
tradicionais.
1RIFIDI - http://www.rifidi.org/2Fosstrak - http://www.fosstrak.org/3Apache TomCat - http://tomcat.apache.org/
51
Figura 4.2: Arquitectura fısica do simulador
Componente DescricaoAplicacao de simulador, que recebe comandos do utilizador
SimEPCIS representa o efeito da accao graficamente e comunica como modulo Groovy console atraves de scripts Groovy
Groovy Console Consola que processa scripts Groovy e executa accoesno ambiente Rifidi
Rifidi Emulator Motor responsavel por criar leitores e etiquetas rfid, adicionar etiquetasa leitores, definir a informacao e estrutura das etiquetas
LLRP Reader Leitor rfid virtual criado no motor RifidiFosstrak LLRP Comander Aplicacao que configura os leitores e respectivos relatoriosFosstrak FC-Server Aplicacao que consome eventos nos leitores, e gera eventos
ALE para as capture applicationsCapture Applications Aplicacao que consome eventos ALE, filtra, e gera eventos EPCIS a inserir nos repositoriosFosstrak EPCIS Repository Repositorio de eventos EPCISERP Modulo com nocoes de negocio que fornece contexto as capture aplications
Tabela 4.2: Descricao de cada componente do simulador
De forma a permitir uma replicacao de cenarios de simulacao, foi disponibilizada uma interface
para carregamento de scripts, constituıdos pelas operacoes identificadas anteriormente.
Na fase final da implementacao do emulador foi escrito um Paper [32] apresentado no workshop
IWRT 2010 – RFID Technology - Concepts, Applications, Challenges.
Apos a implementacao do emulador e escrita do paper, iniciaram-se os testes com o objectivo de
gerar dados para alimentar a rede de rastreabilidade.
Nesta fase o surgiram diversos obstaculos que impediram o sucesso do emulador. O sistema na
sua utilizacao total, geria cerca de 30 leitores rfid, um servidor de eventos ALE, 5 aplicacoes de captura
e repositorios (um por cada organizacao do cenario de teste) e ainda toda a interface do simulador,
assim como o processador de scripts groovy. Este elevado numero de componentes a executar numa
unica maquina, impossibilitou o correcto funcionamento do simulador. Uma vez que que se simulava
o comportamento real do simulador, como a maquina nao tinha capacidade para processar todos os
52
componentes simultaneamente, comecaram-se a detectar falhas na deteccao de objectos. Concluiu-se
que tal se devia ao facto de no instante em que o objecto se encontrava na area de deteccao dos leitores,
o servidor nao tinha capacidade de processar os eventos, descartando os mesmos. Assim a simulacao
apresentava falhas na informacao, nunca se tendo obtido uma simulacao completa com todos os eventos
detectados. Tentaram-se diversas configuracoes ao nıvel dos diversos servidores, mas verificou-se que
a maquina nao tinha recursos suficientes para correr todos os elementos.
Por falta de tempo, e uma vez que se considerava um trabalho secundario, nao se corrigiu o
funcionamento do emulador. Optou-se por realizar uma geracao manual de dados, atraves de uma
alimentacao directa dos repositorios EPCIS. Considerou-se que o trabalho desenvolvido no emulador
foi bastante importante e algo inovador, pelo que se remeteu para trabalho futuro a sua conclusao.
A incapacidade de se obter um emulador funcional, teve um impacto nos objectivos iniciais da
aplicacao, uma vez que se pretendia realizar uma simulacao integrada, com as fases de geracao de
informacao (emulador) realizadas simultaneamente com a fase das perguntas de rastreabilidade. De-
vido a esta incapacidade foram definidos os seguintes pressupostos para o resto do trabalho:
• A captura da informacao e o processamento desta serao realizados em dois instantes distintos.
Assume-se que os repositorios e todos os sistemas auxiliares, possuem a totalidade da informacao
necessaria para a realizacao das pesquisas;
• A execucao das pesquisas teve dois requisitos fundamentais
Todas as organizacoes intervenientes na rede de distribuicao sao conhecidas pela federacao;
As organizacoes e seus componentes podem estar disponıveis ou indisponıveis num determi-
nado momento;
• Os elementos da federacao encontram-se sempre disponıveis;
4.2 Federa�c~ao
A arquitectura definida apresentava diversos componentes tendo-se optado por recorrer a projectos
Open Source sempre que possıvel, de forma reduzir o tempo de implementacao. Os repositorios utili-
zados, assim como o motor de inferencias sao dois exemplos dos projectos utilizados.
A figura 4.2 apresenta os diversos modulos implementados assim como as tecnologias utilizadas.
Os modulos e respectivas tecnologias serao descritos em detalhe, identificando as opcoes tecnicas
tomadas em sede de implementacao.
53
Figura 4.3: Tecnologias utilizadas na implementacao dos diversos modulos
4.2.1 Repositorio EPCIS
O repositorio EPCIS e o elemento tecnologico mais complexo no prototipo utilizado devido ao modelo
de dados que implementa. De forma a reduzir o tempo de implementacao do mesmo, recorreu-se a um
repositorio open source, disponibilizado pelo projecto Fosstrak. Este repositorio respeita a ultima versao
do standard EPCIS e permite a utilizacao de autenticacao nas pesquisas. O repositorio foi implementado
em tecnologia Java e corre sobre um servidor TomCat versao 6. Os dados capturados pelo repositorio
sao armazenados numa base de dados MySQL.
4.2.2 Filtro
O filtro das pesquisas realizadas e, tal como o repositorio, um elemento complexo que foi desenvolvido
recorrendo a duas tecnologias principais. Assente sobre a framework .Net, recorreu-se a esta para reali-
zar a comunicacao e implementacao de todas as comunicacoes via web-services. Com esta framework
foi possıvel, obter os cabecalhos das mensagens, comunicar com a federacao de forma a identificar e
validar as credenciais do cliente e obter a polıtica em vigor para este mesmo cliente. Uma vez obtida a
polıtica, recorreu-se a um motor de inferencias para proceder a avaliacao da mesma, tendo sido selec-
cionado o projecto NxBre como motor de inferencias. Escolheu-se o NxBre por este motor correr sobre
tecnologia .Net, o que facilitaria a invocacao por parte do filtro e pela simplicidade da definicao das
54
regras de inferencias que era realizada atraves de ficheiros xml. O motor de inferencias era alimentado
pela identificacao do grupo e role de ambos os participantes e pela polıtica em vigor. O processamento
do motor de inferencia quantificava o nıvel de detalhe de cada informacao. Este nıvel de detalhe era pos-
teriormente utilizado pelo filtro para proceder ao processamento individual de cada tipo de informacao.
O ficheiro xml definido estava divido em tres seccoes principais:
• definicao de variaveis e constantes;
• identificacao do grupo e role do cliente;
• determinacao do nıvel de detalhe retornado.
A definicao de variaveis e constantes e realizada no inıcio do processamento, e tem
como objectivo preparar o ambiente e carregar toda a informacao necessaria para o proces-
samento da informacao. Este carregamento e realizado recorrendo a uma definicao de cons-
tantes (p.e. <Integer id=”components”value=”1”/>) ou atraves da invocacao explıcita de
metodos get que obtem instancias de objectos e respectivos valores (p.e. <ObjectLookup
id=”Group”objectId=”partner”member=”GroupId”/>).
A seguinte listagem apresenta a seccao inicial de carregamento de uma das polıticas utilizadas neste
trabalho.
1 <xBusinessRules xsi:noNamespaceSchemaLocation=” xBusinessRules . xsd” xmlns :xs i=” h t t p :
//www. w3 . org /2001/XMLSchema−i n s t a n c e ”>
2 <I n t e g e r id=”components” value=”1”/>
3 <I n t e g e r id=” c o n t a i n e r s ” value=”2”/>
4 <I n t e g e r id=” componentscontainers ” value=”3”/>
5 <I n t e g e r id=” aggregat ions ” value=”4”/>
6 <I n t e g e r id=” observat ions ” value=”5”/>
7 <I n t e g e r id=” aggregat ionsobservat ions ” value=”6”/>
8 <I n t e g e r id=” n i l ” value=”0”/>
9 <ObjectLookup id=” Producer ” o b j e c t I d =”group” member=” producer ”/>
10 <ObjectLookup id=” Store ” o b j e c t I d =”group” member=” s t o r e ”/>
11 <ObjectLookup id=” D i s t r i b u t o r ” o b j e c t I d =”group” member=” d i s t r i b u t o r ”/>
12 <ObjectLookup id=” Maintenance” o b j e c t I d =”group” member=” maintenance ”/>
13 <ObjectLookup id=”Group” o b j e c t I d =” partner ” member=”GroupId”/>
14 <ObjectLookup id=” Role ” o b j e c t I d =” partner ” member=” RoleId ”/>
15 <ObjectLookup id=”MyGroup” o b j e c t I d =” myself ” member=”GroupId”/>
16 <ObjectLookup id=”MyRole” o b j e c t I d =” myself ” member=” RoleId ”/>
17 . . .
55
Findo este processo e iniciado o corpo logico da polıtica. No corpo logico, e construıda uma cadeia
de validacoes de forma a testar todas as combinacoes possıveis de grupo e papel desempenhado, que
sejam do interesse da organizacao que disponibiliza informacao. Ou seja se para um determinado grupo,
for indiferente qual o papel do requerente de informacao, este grupo devera ter uma unica regra que e
usada para classificar os dados retornados. A listagem que se segue demonstra algumas das validacoes
e testes realizados no corpo da polıtica.
1 <Logic>
2 < I f>
3 <And>
4 < !−− I d e n t i f i c a c a o do grupo do c l i e n t e −−>
5 <Equals l e f t I d =”Group” r i g h t I d =”MyGroup”/>
6 </And>
7 <Do>
8 < !−− P o l i c y r u l e s f o r same group p a r t n e r s −−>
9 <Logic>
10 < I f>
11 <And>
12 < !−− I d e n t i f i c a c a o do p a p e l do c l i e n t e −−>
13 <Equals l e f t I d =” Role ” r i g h t I d =”MyRole”/>
14 </And>
15 . . .
Finalmente, a seccao final de cada polıtica e a avaliacao do resultado, e definicao dos diversos nıveis
de detalhe. Esta seccao esta presente replicada diversas vezes no ficheiro, uma por cada combinacao
possıvel, definida no corpo logico da polıtica. Estas seccao e facilmente identificada uma vez que e
composta por todas as seccoes iniciadas por <Do >e cujo interior contem um elemento <Evaluate>. A
seguinte listagem demonstra o exemplo de uma regra que recorre igualmente as constantes definidas na
primeira seccao do documento.
1 <Evaluate id=” P o l i c y R e s u l t ”>
2 <Parameter name=”TagType” valueId=” componentscontainers ”/>
3 <Parameter name=”EventType” valueId=” aggregat ionsobservat ions ”/>
4 <Parameter name=” D e t a i l ” value=”−1”/>
5 </Evaluate>
Em anexo encontra-se presente um ficheiro de polıtica completo, onde estao identificados as diver-
sas seccoes aqui descritas.
56
4.2.3 Aplicacao Cliente
Para simplificacao da execucao das pesquisas e melhor visualizacao dos resultados foi construıda uma
aplicacao em .Net para realizacao das diversas pesquisas. Antes da execucao de qualquer pesquisa
a aplicacao autentica-se sempre perante a federacao de forma a validar as credenciais inseridas pelo
utilizador.
As pesquisas a realizar recebiam quatro parametros de entrada:
• Utilizador
• Password
• Codigo EPC
• Tipo de pesquisa a realizar (Track, Trace, Bill-of-Materials)
4.2.4 Discovery Services
A implementacao dos Discovery Services no prototipo recorreu a framework .Net para implementacao
e disponibilizacao dos web-services. Como a rede simulada era de baixa complexidade, optou-se por
nao implementar uma ligacao a base de dados, para gestao dos dados. Em vez disso foi implementada
toda a logica, que consoante o requerente da informacao e o tipo de objecto pretendido, o resultado
da pesquisa era modificado. No caso de uma versao completa da federacao esta ligacao devera ser
construıda e um modelo de base de dados desenhado.
4.2.5 Servidor Polıticas
A semelhanca dos Discovery Services o servidor de polıticas foi implementado sobre a tecnologia .Net e
usando a base de dados MySQL para armazenamento da informacao. Este servico disponibiliza duas
interfaces, uma de insercao/actualizacao de polıticas e outra para consulta de polıticas. A interface de
consultas permite que em runtime um parceiro consiga obter a sua polıtica, de forma a aplicar a mesma.
Em cada invocacao ao servico de proxy, apos autenticacao no servico, obtem do servidor de polıticas a
polıtica em funcionamento e aplica a mesma para filtragem da informacao retornada.
4.2.6 Servico Autenticacao
Tal como os restantes servicos da federacao, o servico de autenticacao foi igualmente implementado
recorrendo a tecnologia .Net. Este dispoe de uma ligacao a uma base de dados MySQL para armaze-
namento dos pares username/password. Apos qualquer autenticacao com sucesso, o servico gera um
57
token de autenticacao que devolve ao cliente e insere na base de dados com a validade de uma hora.
Sempre que um parceiro necessita de validar a autenticacao do cliente, basta que envie a identificacao do
cliente e o respectivo token. O servico na posse desta informacao consulta a base de dados, validando-os
contra os valores existentes e as respectivas validades.
4.3 Dados
De forma a testar o funcionamento da arquitectura proposta foi necessario gerar um conjunto de dados
de teste. Estes dados dividiram-se em duas tipologias, nos dados operacionais de rastreabilidade e nos
dados de controlo da federacao.
Os dados operacionais dizem respeito a todo o conteudo dos repositorios, resultante do funciona-
mento das cadeias de fornecimento, e consequente funcionamento dos leitores e aplicacoes de captura.
Devido a uma inexistencia de dados reais, para simulacao foi necessario recorrer ao prototipo de um
simulador e a configuracoes manuais para os gerar.
Os dados de controlo da federacao sao compostos pela polıticas de partilha de informacao, dados
de controlo dos Discovery Services e servidor de autenticacao. Devido a simplicidade da rede construıda,
estes dados foram gerados e manipulados manualmente.
58
5Avalia�c~ao5.1 Resultados
A execucao e comportamento da arquitectura e solucao proposta foi avaliada segundo uma perspectiva
funcional. A inexistencia de dados reais e a incapacidade do simulador gerar grande quantidades de
dados, inviabilizaram a execucao de testes em grande escala e o registo de metricas, como tempo medio
de execucao, numero de mensagens trocadas e tempo de processamento das polıticas.
Apesar desta incapacidade procedeu-se a uma analise funcional dos requisitos identificados no
inıcio do trabalho identificando para cada um, qual o componente que o verifica (Tabela 5.1).
Procede-se agora a uma explicacao individual de cada requisito e da forma como este e atingido na
arquitectura proposta
5.1.1 Permitir a partilha de informacao entre parceiros
A arquitectura definida assim como todos os seus componentes, foram desenvolvidos com o objectivo
primario de permitir a partilha de informacao entre entidades. Este objectivo foi atingido funcional-
mente durante a comparacao de duas arquitecturas tecnicas no capıtulo anterior.
5.1.2 O fluxo de mensagens simular o fluxo do produto na cadeia de fornecimento
Este requisito e cumprido na execucao das perguntas de track e trace, em que as entidades que participa-
ram na rede de distribuicao, sao contactadas pela mesma ordem que o produto realizou nesta. No caso
de uma BOM nao e possıvel cumprir este requisito devido a propria natureza da pesquisa. Como esta
procede segundo uma metodologia Top-Down e impossıvel identificar, a partida, o inıcio do percurso.
No entanto o fluxo de mensagens e inverso ao fluxo do produto na cadeia, sendo possıvel identificar, a
partir deste, o fluxo original do produto.
Id Requisito EPCIS Discovery Services Polıticas FiltrosFuncional
1 Permitir a partilha de informacaoentre parceiros
2 O fluxo de mensagens simular ofluxo do produto na cadeia
de fornecimento3 Mitigar utilizacoes
abusivas do sistema4 Permitir definir diferentes
nıveis de pesquisa5 Replicar alteracoes nas cadeias,
em alteracoes nos acessos aos dados6 Aceder informacao nos sistemas
de cada entidade em vezde copias locais
7 Suportar uma linguagem de negociopara definir permissoes de acesso
e diferentes nıveis dedetalhe na informacao
8 Capacidade de processar grandesvolumes de dados
Tecnico9 Uniformizar a informacao
dos diversos sistemas10 Definir primitivas
para perguntas de rastreabilidade11 Definir algoritmos
de pesquisa12 Definir sistemas de
autenticacao e autorizacao13 Garantir a escalabilidade do sistema N.A. N.A N.A14 Manter-se operacional
mesmo que existam falhasnum dos elementos
15 Definir e alterarpermissoes de acesso
Tabela 5.1: Requisitos funcionais cumpridos por cada modulo da arquitectura final
60
5.1.3 Mitigar utilizacoes abusivas do sistema
A implementacao das funcionalidades de identificacao e autorizacao permitem mitigar abusos por en-
tidades exteriores ao sistema. Para garantir uma defesa contra entidades que pertencam a propria
federacao e pretendam utilizar os servicos desta, para adquirir uma vantagem sobre os seus compe-
tidores, recorreu-se a nocao de polıticas. Apesar de nao ter sido considerado fundamental, no ambito
deste trabalho, este tipo de ataques, a estrutura desenvolvida permite implementar tecnicas de defesa
dinamicas, atraves da analise do comportamento de cada entidade ao longo do tempo. Caso uma en-
tidade se comporte de forma agressiva, um ajuste nas polıticas de partilha, permite estabelecer um
controlo mais rigoroso das suas actividades e informacao partilhada.
5.1.4 Permitir definir diferentes nıveis de pesquisa
O recurso a nocao de polıticas e regras permite definir para diferentes entidades, diferentes resultados
na pesquisa por um mesmo produto.
5.1.5 Replicar alteracoes nas cadeias, em alteracoes nos acessos aos dados
Alteracoes nos acessos a dados, decorrentes do proprio progresso e actividade da cadeia de distribuicao,
sao facilmente replicados no funcionamento da rede atraves da modificacao das polıticas de partilha.
Desta forma garante-se que um elemento so tem acesso a dados de um determinado produto, depois de
ter interagido com o mesmo.
5.1.6 Aceder informacao nos sistemas de cada entidade em vez de copias locais
A arquitectura foi desenhada de forma a garantir a inexistencia de copia de informacao. Assumiu-se
que o proprietario da informacao detem a totalidade do controlo sobre esta, e que caso existam replicas
de informacao pela rede, estas nunca seriam acedidas. Este controlo e feito atraves dos Discovery Services
que apenas retornam o endereco do proprietario da informacao.
5.1.7 Suportar uma linguagem de negocio para definir permissoes de acesso e dife-
rentes nıveis de detalhe na informacao
Este requisito foi cumprido atraves da adopcao das polıticas de partilha, que atraves de conceitos sim-
ples, mais proximos dos conceitos de negocio, permitem definir o comportamento da federacao.
61
5.1.8 Capacidade de processar grandes quantidades de dados
A divisao dos elementos aplicacionais pelas diversas entidades, tendo cada uma desta o seu proprio
repositorio, permitiu dotar a rede com grandes capacidades no processamento e armazenamento de
dados de rastreabilidade. No caso das pesquisas identificou-se que o passo crıtico na execucao destas,
era o nıvel da execucao do motor de inferencia, que se mantem constante com o aumento do volume de
dados.
5.1.9 Uniformizar a informacao dos diversos sistemas
No capıtulo da arquitectura foi realizado um levantamento das entidades informacionais e respectiva
representacao a adoptar por todos os elementos da rede. Desta forma garantiu-se uma uniformizacao
da informacao, e todos os elementos operam sobre o mesmo modelo.
5.1.10 Definir primitivas para perguntas de rastreabilidade
As primitivas para perguntas de rastreabilidade foram identificadas durante as fases de desenho con-
ceptual e logico da arquitectura.
5.1.11 Definir algoritmos de pesquisa
Tal como o ponto anterior, os algoritmos foram definidos em sede de desenho funcional da arquitectura.
5.1.12 Definir sistemas de autenticacao e autorizacao
Estes sistemas estao presentes nos servicos disponibilizados pela federacao, e sao obrigatorios para to-
dos os clientes que pretendam usar o sistema, uma vez que tanto os Discovey Services como os filtros
colocados nos repositorios requerem autenticacao perante a federacao.
5.1.13 Garantir a escalabilidade do sistema
O desenvolvimento modular de cada componente permitiu que o comportamento e funcionamento
de cada elemento da federacao fosse independente dos restantes. Ja nos componentes de cada
organizacao, estes sao independentes das restantes organizacoes, mas dependentes da federacao ao
nıvel da identificacao e autorizacao de entidades e ainda na gestao e consulta de polıticas. Durante a
execucao deste trabalho, nao foram reunidas as condicoes que permitissem testar e validar a escalabi-
lidade do sistema, em especıfico, nas componentes desenhadas e implementadas para a federacao. De
62
forma a obter conclusoes sobre este requisito seria necessario testar o comportamento da federacao e de-
finir metricas de forma a comparar diversos cenarios e assim ser possıvel extrapolar o comportamento
da federacao num cenario real. As metricas definidas passariam por numero de mensagens trocadas,
tempo medio de processamento e recursos necessarios para processamento. Os diferentes cenarios de-
veriam ser obtidos atraves do aumento do numero de organizacoes e o numero de componentes que
compoem um portatil. A modificacao destas variaveis no cenario definido, teria um impacto directo
no processamento dos algoritmos, quer pelo aumentar do numero de entidades contactadas, quer pelo
aumento da profundidade da recursividade nas pesquisas realizadas.
5.1.14 Manter-se operacional mesmo que existam falhas num dos elementos
Uma vez que sao os Discovery Services que possuem toda a informacao de historico de um produto, ao
nıvel das organizacoes por onde passa, a rede manter-se-a operacional desde que este componente esteja
operacional. A funcionalidade da mesma nao sera afectada pelo estado individual de cada organizacao.
Este estado afectara apenas a qualidade dos resultados obtidos na pesquisa, se este no estiver no cami-
nho do objecto em questao, e nunca o funcionamento global da rede.
5.1.15 Definir e alterar permissoes de acesso
Este requisito e cumprido recorrendo a alteracoes nas polıticas, grupos e roles associados a uma enti-
dade.
63
64
6Conclus~oesO trabalho aqui apresentado, estudou a tematica da rastreabilidade, em redes dinamicas. Estas re-
des tem como principal caracterıstica o facto de poderem albergar distintas cadeias de fornecimento, e
desta forma, disponibilizar servicos comuns a entidades concorrentes. Os principais desafios aborda-
dos, foram a execucao de perguntas de rastreabilidade, garantido a aplicacao de standards existentes e
a definicao de regras para a partilha de informacao.
Para se executarem as perguntas de rastreabilidade, foi necessario definir estruturas de dados, al-
goritmos e interfaces. Uma vez definidos estes elementos, realizou-se uma comparacao funcional de
duas arquitecturas distintas validando-se o cumprimento dos requisitos funcionais identificados para o
sistema.
Ao nıvel da aplicacao das regras para a partilha de informacao, estudou-se a constituicao das redes
de fornecimento segundo grupos e papeis. Posteriormente sugeriu-se a aplicacao de filtros, configura-
dos a partir de polıticas e regras, geridas centralmente pela federacao e aplicadas localmente em cada re-
positorio de dados. Esta solucao permitiu um processamento da informacao existente nos repositorios,
de forma transparente para o utilizador, garantindo que e o proprietario da informacao que define o
detalhe de informacao a partilhar, e validando as restantes recomendacoes da Uniao Europeia.
O trabalho executado segundo estas perspectivas (Rastreabilidade e Polıticas), demonstrou que pela
aplicacao conjunta destas, estao reunidas as condicoes mınimas, para a construcao de redes de rastre-
abilidade dinamicas. Estas redes permitem a execucao de perguntas de rastreabilidade, utilizando tec-
nologia e standards actuais, e possuem a caracterıstica de serem escalaveis, devido ao desenvolvimento
modular.
A maioria dos requisitos definidos inicialmente para os sistemas foram validados, conforme se pode
ver na tabela no capıtulo anterior. Dos requisitos levantados destacam-se os requisitos identificados
pelos numeros 5,7 e 15 que foram a base para a constituicao das polıticas.
A arquitectura apresentada apesar cumprir todas as funcionalidades, pode ainda ser optimizada.
Na seccao trabalho futuro foram apresentadas algumas sugestoes, que nao foram abordadas neste tra-
balho uma vez que nao se consideraram o foco do mesmo, ou devido a algum impedimento durante o
desenvolvimento.
A falta de acesso a dados reais de rastreabilidade e considerada a maior falha neste trabalho, tendo
sido construıdo um simulador para a geracao mınima de dados necessarios de forma a minimizar este
impacto. A construcao do simulador e respectivas decisoes demonstraram-se bastante importantes para
o resultado final deste trabalho, pelo que os resultados observados, foram escritos num artigo e poste-
riormente apresentados num workshop da especialidade. Infelizmente nao foi concluıdo o desenvol-
vimento do simulador manteve-se como prototipo, pelo que esta conclusao e continuacao do estudo
foram adiados e igualmente sugeridos para trabalho futuro.
O trabalho desenvolvido foi um contributo importante para a fase inicial do projecto rfrbnet pelo
levantamento das diversas pesquisas de rastreabilidade e pela definicao das polıticas de modelos de
partilha.
6.1 Trabalho Futuro
O controlo e a rastreabilidade de objectos,o standard EPCIS, juntamente com a IoT formam um conjunto
de areas em franco crescimento. Com este crescimento surgem diversas oportunidades de investigacao
e de aprofundamento do trabalho ja efectuado. O standard EPCIS ainda nao esta fechado o que deixa
algumas incertezas sobre o futuro da rastreabilidade com codigos EPC. Apesar da contınua evolucao
a rastreabilidade e um imperativo para as organizacoes que tem que estar dotadas das ferramentas
que auxiliem os processos de controlo. O trabalho desenvolvido estabeleceu as bases para que novos
caminhos possam ser explorados.
As polıticas definidas e a aplicacao de filtros permitiram dotar a rede de rastreabilidade, com me-
todologias de respostas dinamicas consoante o requerente da informacao. Os filtros aplicados residiram
sobre o modelo de entidades definido, assim sendo surgiu a possibilidade de extender a aplicacao dos
filtros aos restantes elementos informacionais da arquitectura EPCGlobal. Alguns dos elementos dos
eventos EPCIS estao directamente ligados com operacoes de negocio (p.e. bizStep) nao podendo ser
aplicados os filtros como aqui foram definidos. De forma a aplicar a mesma nocao dos filtros, estes
dados deveriam ser remapeados, por outros. A extensao da aplicacao dos filtros assim como o estudo
da aplicacao de mascaras aos dados foram adiados devido a restricoes temporais. Esta impossibilidade
a que se considerasse como trabalho futuro.
Finalmente tecnicas de anonimato de organizacoes sao metodologias de caching de polıticas igual-
mente trabalhos que se podem desenvolver de forma a optimizar a solucao proposta.
O simulador SimEPCIS podera ser a ferramenta ideal para qualquer organizacao testar e simular o
ambiente que pretende controlar. Apesar de totalmente implementado, o simulador nunca se mostrou
funcional devido a complexidade da aplicacao. O facto de utilizar componentes para simular todos os
passos desde a deteccao ate ao registo do evento, leva a aplicacao a tornar-se algo instavel. Mantendo
66
a utilidade de simulador, e de forma a simplificar a estrutura da aplicacao, esta deveria inserir os even-
tos ja processados directamente no repositorio, anulando os componentes de simulacao dos leitores e
restantes aplicacoes. Desta forma seria possıvel construir um simulador, mantendo a mesma estrutura
logica de funcionamento mas simplificando os processos internos de geracao de eventos. Com o simu-
lador totalmente funcional, seria possıvel gerar um volume de dados suficiente, para realizar testes de
carga e performance, sobre as duas arquitecturas propostas.
Finalmente apresentam-se alguns trabalhos que se podem desenvolver sobre a arquitectura pro-
posta, que nao estando directamente relacionados com o trabalho desenvolvido, podem contribuir para
tornar este sistema comercial:
• Estudar e propor um modelo de negocio sobre a rede, de forma a financiar os custos operacionais
da mesma, por exemplo, cobrando uma taxa por cada query, criando um mercado ou bolsa de
pesquisas, etc;
• Identificar formas de agrupar eventos redundantes, reduzindo a quantidade de dados a processar;
• Estudar um modo de efectuar um mapeamento das rotas de distribuicao recorrendo a diversas
tecnologias(GPS, mapas online, etc);
• Estudar um metodo para optimizacao das rotas de distribuicao, em que participem duas ou mais
entidades;
• Analisar um modelo alternativo, centralizado nos objectos em vez de nos eventos;
• Estudar o recurso ao cloud computing para diminuicao dos custos operacionais atraves da migracao
de diversos componentes da federacao para a ”nuvem”;
67
68
Bibliogra�a
[1] J. Gattorna, Dynamic Supply Chain Alignment: A New Business Model for Peak Performance in Enterprise
Supply Chains Across All Geographies, Chapter 4. Gower Pub Co, 2009.
[2] PricewaterhouseCoopers, “Future of World Trade - Top 25 sea and air freight routes in 2030,” 2010.
[3] P. Europeu, “ Commission Directive 2009/120/EC of amending Directive 2001/83/EC on the Com-
munity code relating to medicinal products for human use as regards advanced therapy medicinal
products.” 2009.
[4] Eurostat, “Energy, transport and environment indicators,” 2010.
[5] C. Europeia, “Relatorio da Comissao ao Conselho e ao Parlamento Europeu sobre a aplicacao do
Regulamento (CE) n.◦1830/2003 do Parlamento Europeu e do Conselho relativo a rastreabilidade e
rotulagem de organismos geneticamente modificados e a rastreabilidade dos generos alimentıcios e
alimentos para animais produzidos a partir de organismos geneticamente modificados e que altera
a Directiva 2001/18/CE,” 2003.
[6] ——, “ Directiva 2008/43/CE da Comissao, de 4 de Abril de 2008, que cria, nos termos da Directiva
93/15/CEE do Conselho, um sistema para a identificacao e rastreabilidade dos explosivos para
utilizacao civil.” 2008.
[7] EPCGlobal, “ Pedigree Ratified Standard, 3 Version 1.0,” 5 Janeiro 2007.
[8] C. R. Karin Murthy, “A Model-based Comparative Study of Traceability Systems,” IBM, Tech. Rep.,
2008.
[9] S. Haller and S. Hodges, “White paper - the need for a universal smartsensor network,” Institute
for Manufacturing, University of Cambridge, Auto-ID Labs, Tech. Rep., 11 2002.
[10] C. O. T. E. COMMUNITIES, “Internet of Things — An action plan for Europe, Communication
from the commission to the European parliament, the council, the European economic and social
committee and the committee of the regions, Brussels,” 2009.
[11] A. de Saint-Exupery, “Internet of things Strategic research Roadmap,” 2009.
[12] H. Clampitt, “RFID vs Bar Codes,” 2005.
69
[13] B. P. L Zhekun, R Gadh, “Applications of RFID technology and smart parts in manufacturing -
Proceedings of DETC,” in ASME 2004 Design Engineering Technical Conferences and Computers and
Information in Engineering Conference, 2004.
[14] G. P. Gareth R.T. White, Georgina Gardiner and A. A. Razak, “A comparison of barcoding and
rfid technologies in practice,” Journal of Information, Information Technology and Organizations, pp.
119–132, 2007.
[15] M. Buettner and D. Wetherall, “An empirical study of uhf rfid performance,” in in Proc. 14th ACM
Int. Conf. on Mobile Computing and Networking (MobiCom, pp. 223–234.
[16] R. Angeles, “Rfid technologies: Supply-chain applications and implementation issues,” Information
Systems Management, vol. 22, no. 1, pp. 51–65, 2005.
[17] D. L. B. Edmund W. Schuster, Stuart J. Allen, Global RFID: the value of the EPCglobal Network for
supply chain management, Part I Chapter 3. Springer, 2007.
[18] K. M. Luke McCathie, “Is it the end of barcodes in supply chain management?” in Collaborative
Electronic Commerce Technology and Research Conference LatAm, University of Talca, Chile, 2005.
[19] D. L. Brockc, “ White Paper, The Electronic Product Code (EPC), A Naming Scheme for Physical
Objects,” Massachussets Institute of Technology, Tech. Rep., 2001.
[20] EPCGlobal, “EPC Information Services (EPCIS) version 1.0.1 Specification,” 2007.
[21] EPCglobal, “Object Name Service (ONS) 1.0.1,” 2008.
[22] S. Beier, T. Grandison, K. Kailing, and R. Rantzau, “Discovery services-enabling rfid traceability in
epcglobal networks.” in COMAD’06, 2006, pp. 214–217.
[23] J. Cantero, M. Guijarro, G. Arrebola, E. Garcia, J. Baos, M. Harrison, and T. Kelepouris, “Traceability
applications based on discovery services,” in Emerging Technologies and Factory Automation, 2008.
ETFA 2008. IEEE International Conference on, sept. 2008, pp. 1332 –1337.
[24] S. R. Cambridge University, BT Research, “Serial-Level Inventory Tracking Model,” 2007.
[25] N. R. Reid, R. Dan; Sanders, “Operations Management,” 2002.
[26] N. E. M. I. Inc., “In Search of the Perfect Bill of Materials (BoM),” 2002.
[27] R. Agrawal, A. Cheung, K. Kailing, and S. Schonauer, “Towards Traceability across Sovereign, Dis-
tributed RFID Databases,” in International Database Engineering and Applications Symposium (IDEAS),
2006.
70
[28] F. Thiesse, C. Floerkemeier, M. Harrison, F. Michahelles, and C. Roduner, “Technology, standards,
and real-world deployments of the EPC network,” IEEE Internet Computing, vol. 13, no. 2, pp. 36–43,
2009.
[29] D. Kossmann, “The state of the art in distributed query processing,” ACM Comput. Surv., vol. 32,
pp. 422–469, December 2000. [Online]. Available: http://doi.acm.org/10.1145/371578.371598
[30] R. Schollmeier, “A definition of peer-to-peer networking for the classification of peer-to-peer archi-
tectures and applications,” in Peer-to-Peer Computing, 2001. Proceedings. First International Conference
on, aug 2001, pp. 101 –102.
[31] J. B. A. R. IBM, Maryann Hondo, “Policies and Rules – Improving business agility,” 2010.
[32] C. Perdigao and M. Pardal, “Epc virtual lab: Experiments using an rfid location simulator,” IWRT
2010, pp. 108 – 113, 2010.
71
72
Appendices
73
.1 Exemplo Pol��tica
Neste anexo sera apresentado o ficheiro xml, onde estao representadas as regras de negocio definidas,
para as polıticas utilizadas pelos filtros. Neste exemplo apresenta-se a polıtica executada pela loja do
cenario do portatil. Nesta polıtica a loja nao partilha informacao com outras lojas nem com elementos
externos ao grupo. Os restantes elementos tem acesso a diferentes tipos de informacao, variando entre o
tipo de objectos (componentes, contentores ou ambos), de eventos (observacoes, agregacoes ou ambos)
e o tipo de detalhe da informacao ( total, nulo ou outro).
Para facilitar a compreensao do ficheiro, foram identificadas as diversas seccoes identificadas no
capıtulo da implementacao. Esta identificacao recorreu a delimitacoes sob a forma de comentarios.
1 <xBusinessRules xsi:noNamespaceSchemaLocation=” xBusinessRules . xsd” xmlns :xs i=” h t t p :
//www. w3 . org /2001/XMLSchema−i n s t a n c e ”>
2 < !−− I n i c i o do c a r r e g a m e n t o −−>
3 <I n t e g e r id=”components” value=”1”/>
4 <I n t e g e r id=” c o n t a i n e r s ” value=”2”/>
5 <I n t e g e r id=” componentscontainers ” value=”3”/>
6 <I n t e g e r id=” aggregat ions ” value=”4”/>
7 <I n t e g e r id=” observat ions ” value=”5”/>
8 <I n t e g e r id=” aggregat ionsobservat ions ” value=”6”/>
9 <I n t e g e r id=” n i l ” value=”0”/>
10 <ObjectLookup id=” Producer ” o b j e c t I d =”group” member=” producer ”/>
11 <ObjectLookup id=” Store ” o b j e c t I d =”group” member=” s t o r e ”/>
12 <ObjectLookup id=” D i s t r i b u t o r ” o b j e c t I d =”group” member=” d i s t r i b u t o r ”/>
13 <ObjectLookup id=” Maintenance” o b j e c t I d =”group” member=” maintenance ”/>
14 <ObjectLookup id=”Group” o b j e c t I d =” partner ” member=”GroupId”/>
15 <ObjectLookup id=” Role ” o b j e c t I d =” partner ” member=” RoleId ”/>
16 <ObjectLookup id=”MyGroup” o b j e c t I d =” myself ” member=”GroupId”/>
17 <ObjectLookup id=”MyRole” o b j e c t I d =” myself ” member=” RoleId ”/>
18 < !−− Fim do Carregamento −−>
19 < !−− I n ı c i o do c o r p o l o g i c o −−>
20 <Logic>
21 < I f>
22 <And>
23 < !−− I d e n t i f i c a c a o do grupo do c l i e n t e −−>
24 <Equals l e f t I d =”Group” r i g h t I d =”MyGroup”/>
25 </And>
26 <Do>
75
27 < !−− P o l i c y r u l e s f o r same group p a r t n e r s −−>
28 <Logic>
29 < I f>
30 <And>
31 < !−− I d e n t i f i c a c a o do p a p e l do c l i e n t e −−>
32 <Equals l e f t I d =” Role ” r i g h t I d =”MyRole”/>
33 </And>
34 <Do>
35 < !−− I n ı c i o da a v a l i a c a o do r e s u l t a d o −−>
36 <Evaluate id=” P o l i c y R e s u l t ”>
37 <Parameter name=”TagType” valueId=” n i l ”/>
38 <Parameter name=”EventType” valueId=” n i l ”/>
39 <Parameter name=” D e t a i l ” valueId=” n i l ”/>
40 </Evaluate>
41 < !−− Fim da a v a l i a c a o −−>
42 </Do>
43 </ I f>
44 <E l s e I f>
45 <And>
46 <Equals l e f t I d =” Role ” r i g h t I d =” D i s t r i b u t o r ”/>
47 </And>
48 <Do>
49 < !−− I n ı c i o da a v a l i a c a o do r e s u l t a d o −−>
50 <Evaluate id=” P o l i c y R e s u l t ”>
51 <Parameter name=”TagType” valueId=” componentscontainers ”/>
52 <Parameter name=”EventType” valueId=” aggregat ionsobservat ions ”/>
53 <Parameter name=” D e t a i l ” value=”−1”/>
54 </Evaluate>
55 < !−− Fim da a v a l i a c a o −−>
56 </Do>
57 </ E l s e I f>
58 <E l s e I f>
59 <And>
60 <Equals l e f t I d =” Role ” r i g h t I d =” Producer ”/>
61 </And>
62 <Do>
63 < !−− I n ı c i o da a v a l i a c a o do r e s u l t a d o −−>
64 <Evaluate id=” P o l i c y R e s u l t ”>
65 <Parameter name=”TagType” valueId=”components”/>
76
66 <Parameter name=”EventType” valueId=” observat ions ”/>
67 <Parameter name=” D e t a i l ” value=”1”/>
68 </Evaluate>
69 < !−− Fim da a v a l i a c a o −−>
70 </Do>
71 </ E l s e I f>
72 <E l s e I f>
73 <And>
74 <Equals l e f t I d =” Role ” r i g h t I d =”Maintenance”/>
75 </And>
76 <Do>
77 < !−− I n ı c i o da a v a l i a c a o do r e s u l t a d o −−>
78 <Evaluate id=” P o l i c y R e s u l t ”>
79 <Parameter name=”TagType” valueId=” componentscontainers ”/>
80 <Parameter name=”EventType” valueId=” aggregat ions ”/>
81 <Parameter name=” D e t a i l ” value=”−1”/>
82 </Evaluate>
83 < !−− Fim da a v a l i a c a o −−>
84 </Do>
85 </ E l s e I f>
86 <Else>
87 < !−− I n ı c i o da a v a l i a c a o do r e s u l t a d o −−>
88 <Evaluate id=” P o l i c y R e s u l t ”>
89 <Parameter name=”TagType” valueId=”components”/>
90 <Parameter name=”EventType” valueId=” observat ions ”/>
91 <Parameter name=” D e t a i l ” value=”1”/>
92 </Evaluate>
93 < !−− Fim da a v a l i a c a o −−>
94 </Else>
95 </Logic>
96 </Do>
97 </ I f>
98 <Else>
99 < !−− I n ı c i o da a v a l i a c a o do r e s u l t a d o −−>
100 < !−− P o l i c y r u l e s f o r o u t s i d e r s −−>
101 <Evaluate id=” P o l i c y R e s u l t ”>
102 <Parameter name=”TagType” valueId=” n i l ”/>
103 <Parameter name=”EventType” valueId=” n i l ”/>
104 <Parameter name=” D e t a i l ” valueId=” n i l ”/>
77
105 </Evaluate>
106 < !−− Fim da a v a l i a c a o −−>
107 </Else>
108 < !−− Fim do c o r p o l o g i c o −−>
109 </Logic>
110 </xBusinessRules>
78