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