I-Locate: Sistema de monitoramento e localização de usuários no HUB utilizando a tecnologia RFID

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação I-Locate: Sistema de monitoramento e localização de usuários no HUB utilizando a tecnologia RFID Ilmar Ferreira Marques Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Orientadora Prof ā. Dr ā. Carla Denise Castanho Brasília 2008

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Computação Licenciatura Coordenador: Prof. Dr. Flávio Leonardo Cavalcanti de Moura Banca examinadora composta por: Prof ā. Dr ā. Carla Denise Castanho (Orientadora) CIC/UnB Prof. Dr. Ricardo Pezzuol Jacobi CIC/UnB Prof ā. Dr ā. Célia Ghedini Ralha CIC/UnB CIP Catalogação Internacional na Publicação Marques, Ilmar Ferreira. I-Locate: Sistema de monitoramento e localização de usuários no HUB utilizando a tecnologia RFID / Ilmar Ferreira Marques. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, Identificação por rádio frequência, 2. auto-identificação, 3. sistema de localização, 4. RFID CDU 004 Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação I-Locate: Sistema de monitoramento e localização de usuários no HUB utilizando a tecnologia RFID Ilmar Ferreira Marques Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Prof ā. Dr ā. Carla Denise Castanho (Orientadora) CIC/UnB Prof. Dr. Ricardo Pezzuol Jacobi CIC/UnB Prof ā. Dr ā. Célia Ghedini Ralha CIC/UnB Prof. Dr. Flávio Leonardo Cavalcanti de Moura Coordenador do Curso de Computação Licenciatura Brasília, 06 de Dezembro de 2008

4 Agradecimentos Agradeço, restritivamente, a Deus pela força e saúde que me constituem.

5 Resumo A importância do controle de acesso de pessoas em um ambiente hospitalar se torna fundamental quando se leva em consideração o papel do mesmo, que é a prestação de serviços na área de saúde com qualidade, eficiência e eficácia. Com isso, é relevante assegurar a finalidade do serviço hospitalar através do controle das pessoas que nela transitam, isto é, o controle de acesso físico às suas dependências. Com mesma importância, certificar-se de que cada um dos usuários transitantes, dentre pacientes, médicos, visitantes, funcionários e colaboradores, estão nas dependências físicas autorizadas requer monitoração constante da movimentação dos mesmos pela equipe de segurança do hospital. Esta equipe é responsável pelo zelo do patrimônio hospital e age proativamente contra qualquer de adversidade que possa colocar em risco a ordem do estabelecimento. Neste sentido, há dificuldades implícitas a própria atividade de monitoração caso a mesma seja realizada contando apenas com agentes de segurança desprovidos de equipamento e tecnologia para tal finalidade. Uma atividade típica de monitoração de usuários dentro de um hospital querer a disponibilização de pelo menos um agente para observálo. Levando em conta que o número de usuários dentro de um hospital ultrapassa com facilidade o número de vigilantes, numa condição ideal de monitoração seria inviável que todos os usuários estariam de fato sendo monitorados. O presente trabalho propõe um sistema informatizado que cujo o objetivo é auxiliar o controle e garantia da acesso de pessoas aos diversos espaços físicos que constituem o HUB - Hospital Universitário de Brasília. A solução proposta baseiase na utilização da tecnologia de identificação por rádio frequência, RFID. Em se tratando deste elemento, a tecnologia RFID, ainda em processo de maturação no Brasil, destaca-se por ser um método de identificação automatizada que utiliza ondas eletromagnéticas para acessar dados armazenados em um microchip. Palavras-chave: Identificação por rádio frequência, auto-identificação, sistema de localização,rfid

6 Sumário Capítulo 1 Introdução 8 Capítulo 2 Análise do problema Introdução O Hospital Universitário de Brasília Apresentação, estrutura física e organizacional Níveis de Acesso e Problemas de Segurança Objetivos e Proposta Capítulo 3 Fundamentação Teórica A tecnologia RFID Introdução A História da RFID A Arquitetura da tecnologia RFID Padrão EPCGlobal Redes RFID Distribuídas Aplicações da tecnologia de identificação por rádio frequência Computação Ubíqua Capítulo 4 Sistema de controle e monitoração de acesso: I-Locate Processos de negócio existentes na instituição Necessidades do sistema Introdução Requisitos funcionais Premissas de funcionamento Arquitetura do software Módulo do leitor RFID Módulo do middleware Gerador de eventos EPCIS Módulo EPCIS Módulo ILOCATEWEB Apresentação do software I-Locate Gerenciar acesso a dependências físicas Gerenciar usuários Gerenciar etiquetas Administrar usuários do sistema Administrar sistema

7 Capítulo 5 Conclusão Trabalhos futuros Referências 100 7

8 Capítulo 1 Introdução Garantir a segurança em hospitais significa prover meios de proteção para todos as pessoas que interagem na execução do serviço de saúde, zelando por áreas públicas e privadas contra ações diversas que possam afetar tal execução. Em um hospital as áreas publicas são aquelas onde não há controle de acesso, ou seja, são de acesso livre e indiscriminado, diferentemente das á áreas privadas, as quais são tipicamente áreas onde deve prevalecer a fiscalização quanto ao propósito do usuário no local onde se encontra. De maneira geral, os hospitais formam uma mescla de áreas com acesso restrito e irrestrito, com equipamentos de alto custo, e uma diversidade de pessoas, dentre funcionários, pacientes, médicos, visitantes e colaboradores, movendo-se em seu interior. Tais características peculiares deste ambiente tornam o aspecto do controle e monitoração de acesso as suas dependências uma questão de fundamental importância. Neste contexto, garantir a segurança é função da equipe de segurança interna do hospital. A esta equipe cabe estabelecer e zelar pela ordem no recinto hospitalar através de ações ativas de segurança. Um hospital que não possa desempenhar, neste aspecto, seu papel abre possibilidades para a proliferação de ocorrências que podem afetar a qualidade da execução do serviço hospitalar. Furtos de equipamentos de alto custo, adversidades causadas pelo estado emocional dos pacientes, e acesso a áreas de risco de contaminação, são alguns exemplos destas ocorrências. Levando-se em conta que em uma condição real de monitoração do espaço físico privado deve ser feito aos olhos humanos, diretamente - a olho nú, ou indiretamente - através de câmeras, a todos os usuários que nela transitam, a mobilização de um alto grau de recursos da equipe de segurança é realizado. O motivo é inerente a própria atividade de monitoração e sua execução em estado ideal custaria caro para a organização. Neste sentido, aborda-se o ponto acima como motivação da presente monografia no contexto do Hospital Universitário de Brasília (HUB), que atualmente conta somente com algumas câmeras de monitoração espalhadas em pontos estratégicos do hospital. A instituição não dispõe de nenhuma ferramenta informatizada para monitoração e controle de acesso as suas dependências. O serviço de segurança hospitalar carece de um sistema informatizado que possa auxiliar na solução deste problema de maneira eficiente e eficaz. Diversas tecnologias, como código de barras, biometria, identificação por voz, e reconhecimento por característica ótica (OCR), tem sido amplamente estudadas e 8

9 utilizadas para auto-identificação de objetos e/ou seres humanos. Entretanto, nos últimos anos, a tecnologia RFID (Radio-frequency identification), ou identificação por rádio frequência, tem ganhado espaço nas pesquisas relacionadas a autoidentificação e ao controle de acesso de pessoas a ambientes monitorados. Um sistema baseado na tecnologia RFID é capaz de identificar uma pessoa ou objeto com eficiência, podendo também fornecer informações acerca do mesmo a fim de possibilitar a tomada de decisão com base na localização da pessoa ou objeto identificado. O objetivo deste trabalho é propor um sistema informatizado de monitoramento e controle de usuário no HUB utilizando a tecnologia RFID. Esta monografia está organizada da seguinte forma: O capítulo 2 aborda o problema atacado por este trabalho no contexto do Hospital Universitário de Brasília. No capítulo 3 são introduzidos os fundamentos teóricos da tecnologia RFID, bem como os elementos base para a construção de um sistema RFID. No capítulo 4 é apresentado o sistema proposto baseado na tecnologia RFID para o problema de monitoramento e controle de acesso do HUB. Por fim, o capítulo 5 conclui esta monografia além de indicar alguns trabalhos futuros para continuidade desta pesquisa. 9

10 Capítulo 2 Análise do problema 2.1 Introdução O controle do fluxo de pessoas em qualquer organização é vital para o seu bom funcionamento. Desde motivos mais triviais até os mais relevantes, o controle e a segurança contribuem de forma bastante positiva para que a organização venha a ter um ótimo desempenho. Isso se intensifica ainda mais em se tratando de um hospital, já que o atendimento a pessoas é o fator primordial para o sucesso da organização. O Hospital Universitário de Brasília - HUB - atualmente carece de um controle eficaz deste processo, conforme levantamento e estudo apresentado em 10

11 [Davi Silva, 2006]. O trâmite do controle de entrada e saída de pessoas é prejudicado, fazendo com que o atendimento ao público reduza sua qualidade, haja vista a importância do controle e monitoração de acesso nas dependências físicas da organização. Tem-se então, uma situação com alta sensibilidade já que esse cenário se reflete não só nos pacientes, que podem ter sua recuperação prejudicada pelo excesso de pessoas, mas também nos médicos, que tem seus trabalhos interferidos de maneira inesperada e na garantia de segurança de áreas de acesso selecionado como por exemplo os laboratórios. Além disso, problemas de furto de medicamentos e pequenos objetos hospitalares, alguns de alto valor, tem maior probabilidade de ocorrência caso não seja cedida a devida atenção ao ponto citado. É diante deste cenário que o controle de acessos atua. Uma boa administração neste processo da organização atinge todos os envolvidos nela, desde os médicos e funcionários, até os pacientes e visitantes. 2.2 O Hospital Universitário de Brasília Apresentação, estrutura física e organizacional O Hospital Universitário de Brasília (HUB)[HUB, 2007] teve seu funcionamento autorizado pelo Decreto n. o de 21 de fevereiro de Nessa fase inicial, era mantido pelo Instituto de Pensão e Aposentadoria dos Servidores do Estado (IPASE). Foi inaugurado, oficialmente, em agosto de 1972, pelo então Presidente da República, General Emílio Garrastazu Médici, recebendo o nome de Hospital dos Servidores da União (HSU). Em 1990, foi cedido à Universidade de Brasília (UnB) em ato assinado pelo Presidente Fernando Collor e passou a se chamar Hospital Universitário de Brasília (HUB). O HUB conta atualmente com 289 leitos, 121 salas de Ambulatório e metros quadrados de área construída. Seu corpo clínico é formado por diversos profissionais da área de saúde: Professores da UnB, servidores do Ministério da Saúde e profissionais contratados. Segundo informações[hub, 2007], seu atendimento ambulatorial é, em média, de consultas, com cerca de 900 internações. O Pronto Socorro realiza, aproximadamente, consultas. No total, o HUB faz atendimentos a cada mês. São feitos cerca de exames complementares e 500 intervenções cirúrgicas/mês. O HUB, contando atualmente com 33 especialidades médicas, serve à comunidade do Distrito Federal nos níveis primário, secundário e terciário, recebendo ainda pacientes das cidades do entorno de Brasília e oriundos de várias outras unidades da federação. As figuras 2.1 e 2.2 mostram as fotos do hospital na visão aérea e frontal. Da perspectiva da hierarquia organizacional, o HUB é parte da Universidade de Brasília, portanto fica sujeito às imposições em nível macro, impostas pelas políticas adotadas pela Reitoria da Universidade. Embora o HUB possua autonomia para determinar suas atividades e seu funcionamento, ele acaba sofrendo com qualquer política adotada para a UnB. Abaixo das decisões políticas refletivas 11

12 Figura 2.1: Visão áerea do HUB. Figura 2.2: Visão frontal do HUB. 12

13 Figura 2.3: Estrutura organizacional do HUB. 13

14 pela reitoria, tem-se o conselho deliberativo o qual compete promover o relacionamento institucional do HUB com as atividades que a ele compete. Subordinado ao conselho deliberativo tem-se a diretoria cuja responsabilidade é de superintender, coordenar e fiscalizar as atividades do HUB. A figura 2.3 mostra a organização de forma hierárquica e as relações entre a reitoria da UnB, do conselho deliberativo, da diretoria do hospital e dos demais componentes subordinados a estes. Sob o ponto de vista físico, o HUB é formado por três elementos principais: os Centros Ambulatoriais, o Anexo I e o Anexo II. Embora o HUB possua mais alguns complexos, como o Centro do Idoso ou o prédio da administração, esses três centros apresentam problemas mais críticos com relação ao controle de acesso de pessoas, pois são os possuem um fluxo maior de público externo. A descrição do funcionamento destes complexos são feitas abaixo. Ambulatório O Ambulatório é o local responsável pelo atendimento clínico de pacientes. Praticamente todas as especialidades da saúde atuam neste complexo, prestando atendimento aos pacientes que possuam hora marcada. Mensalmente, após o dia 15, são abertas novas vagas para atendimento. O número de vagas para cada área varia, observando a disponibilidade médica. Sendo assim os pacientes, a partir deste dia, entram em contato com o setor de informações do Ambulatório que os encaminha para a marcação de consultas caso haja a disponibilidade requerida pela pessoa. A marcação também pode ser efetiva pessoalmente, o quê não garante a existência de vagas. Devido a essa intermitência, o número de pessoas no complexo varia muito. A arquitetura do local também dificulta, pois embora apenas duas entradas estejam operando atualmente, o número de corredores e a disposição dos locais de marcação de consulta não são centralizados em ponto único, sendo que ao invés disso cada consulta é marcada localizações nas respectivas localizações da especialidade em questão. Atualmente não existe controle de acesso neste complexo sendo a entrada para funcionários, visitantes ou pacientes. Anexo I e Anexo II O Anexo I possui uma grande diversidade de funções. UTI, laboratórios, centro cirúrgico, e Diretoria de Estudos de Graduação, são alguns exemplos. No Anexo II a situação não é diferente. Capela, Central telefônica, Fisioterapia e Odontologia integram alguns dos setores que atuam neste prédio. Diante disso, constata-se que o interesse das pessoas de entrar nas dependências deste local varia muito. O controle atual é centralizado, ou seja, para qualquer um dos Anexos o acesso deve ser adquirido em um guichê situado no Anexo I. Os níveis de acesso são variados, dependendo da pessoa e do andar que tenta acessar. Um problema recorrente, por exemplo, é na Odontologia (1 o andar Anexo II), onde o acesso é livre, e na Internação (2 o andar Anexo II), onde o acesso é restrito. Muitas pessoas sobem até a Internação clamando ir para a Odontologia. Isso, sem mencionar os problemas no próprio andar da Odontologia. Lá a exposição de vários equipamentos pequenos e valiosos ficam a disposição para furto, de modo a trazer 14

15 vários prejuízos ao hospital. O controle é totalmente manual, sendo realizado um registro em cadernos e guias, além do controle dos seguranças, que abrem e fecham a porta de acordo com a liberação de entrada. A monitoração da regularidade dos usuários que estão adentro da dependências físicas é realizado pela segurança interna por meio do reconhecimento das cores de adesivos cedidos na entrada do portador. Entretanto a falta de agentes para fiscalizar as cores nas devidas dependências torna o processo debilitado. De maneira diferente os funcionários não precisam utilizar tais adesivos pois para o trâmite no hospital é restringido pelo crachá ou pelos uniformes relativos as funções do hospital (Ex.: jaleco) Níveis de Acesso e Problemas de Segurança Nesta seção são apresentadas, para cada um dos principais prédios do hospital, as principais deficiências relacionadas ao controle de acesso de pessoas no Hospital Universitário de Brasília. Antes, é preciso destacar duas importantes normas administrativas que dizem respeito ao número e acesso de visitantes ao hospital: Acompanhante e Visitante: Alguns pacientes podem ter uma pessoa os acompanhando fora do horário de visita. Idosos, crianças e os em situação especial são os casos que tem direito a acompanhante. Já o visitante só tem autorização para entrar nos horários determinados para visita; Paciente conveniado e Paciente sem convênio: a diferença é o número de visitantes que cada um pode receber simultaneamente. O conveniado pode receber dois visitantes, e o sem convênio pode receber apenas um. Note que o acompanhante conta para este limite. No caso de um paciente sem convênio, por exemplo, no horário de visita, o acompanhante deverá se retirar do hospital para que outra pessoa visite o paciente. Anexo I Térreo e 1 o andar: o acesso é restrito. Não há um número limite de pessoas em cada setor e as atividades efetuadas neste andar são muito variadas. Ali existem salas de exames, laboratórios, refeitórios e lavanderias, setor de faturamento, internação e alta, além da Diretoria Adjunta de Ensino e Pesquisa. Diante deste cenário no qual os motivos de acesso são variados percebe-se a dificuldade de se implementar um controle que garanta que um certo indivíduo vá para onde se prontificou a ir no momento da identificação na portaria. O controle acaba recaindo no processo de controle do trâmite interno, por meio dos adesivos entregues na portaria. 2 o,3 o e 4 o andares: locais de internações. O controle se torna facilitado já que existe um horário pré-determinado para as visitas (todos os dias - 15hs às 16hs). Conforme descrito acima, o limite de visitantes por paciente são dois para os pacientes conveniados, e apenas um para os demais. Nos outros horários o acesso ao público fica proibido, salvo no caso dos acompanhantes. Pacientes idosos, crianças e alguns casos específicos tem direito a um acompanhante cada, 15

16 ou seja, uma pessoa pode acompanhá-los independente do horário. Anexo II Térreo e 1 o andar: o acesso é livre. O problema recorrente é que a Odontologia (1 o andar) sofre furtos já que seus equipamentos são pequenos e de fácil ocultamento. 2 o andar: local de internações. O número de visitantes também segue os padrões do Anexo I. Um outro problema apontado neste local é que, como no 1 o andar e no térreo o acesso é livre, muitos usuários informam seu destino final como a odontologia, mas sobem para o 2 o andar, onde encontram-se os pacientes internados. Somente em alguns horários é designado um agente de segurança para vigiar o acesso ao 2 o piso. Além dos problemas de segurança do local descritos acima, foi identificado uma deficiência relacionada ao fluxo de pessoas. Visitantes que se dirigem a certos pontos precisam requerer uma autorização em um guichê do Anexo I, gerando um deslocamento desnecessário. Ambulatório Térreo: local de consultas previamente agendadas. Aqui o principal problema é a arquitetura e a organização do ambiente. A disposição do local de marcação de consultas dificulta o estabelecimento de um bom local para a recepção dos pacientes. Além das questões apresentadas, outros dois fatores fundamentais a serem considerados para a realização deste projeto são: (1) a necessidade de silêncio constante na maior parte das dependências do hospital, por razões óbvias que envolvem o bem-estar dos pacientes; (2) o tamanho do hospital e o fluxo constante de pessoas, macas e cadeiras de rodas, que limitam as regiões onde podem ser passados fios ou instalados equipamentos no HUB. 2.3 Objetivos e Proposta Com o objetivo de minimizar as questões apresentadas na seção anterior, que comprometem tanto a segurança do hospital, como a qualidade dos serviços prestados, este trabalho propõe um sistema informatizado como ferramenta de apoio à equipe de segurança HUB. A ferramenta possibilitará a equipe controlar o acesso de qualquer usuário às dependências do hospital, bem como monitorar a localização dos mesmos. Dessa forma, pretende-se alcançar a realização da atividade de controle e monitoração de pessoas de forma mais eficiente, sem a demanda de novos recursos humanos da equipe de segurança. A ferramenta de software proposta neste trabalho, será baseada na tecnologia de identificação por rádio frequência, ou seja, RFID. O sistema será desenvolvido através de técnica de modelagem de dados estruturada, e diagramas de atividades UML para entender os processos de negócios existentes na área de controle de acesso e monitoração de usuários. Além disso, serão expostos os requisitos funcionais do sistema juntamente com a proposta de melhoria para as atividades 16

17 existentes com a integração da tecnologia RFID. Além, da arquitetura do software será apresentada a interface final com usuário e a documentação dos casos de usos pertinentes às funcionalidades oferecidas pelo sistema. 17

18 Capítulo 3 Fundamentação Teórica 3.1 A tecnologia RFID Introdução A tecnologia de RFID (Radio Frequency Identification - identificação por rádio frequência) oferece benefícios para os tipos de problemas que precisam identificar a localização de itens físicos. Ela utiliza ondas de rádio para identificação automática, reconhecendo desde itens inanimados até seres humanos. Com isso, pode-se incluir identificação para os itens físicos, atribuindo para cada objeto uma identificação única, assemelhando-se assim aos códigos de barra que existem hoje para individualização de itens de um supermercado. A maneira de atribuir informação aos objetos é juntando adesivos chamados de etiquetas RFID aos objetos a serem identificados. Estas etiquetas possuem um circuito capaz de reagir ao estímulo de ondas de rádio, fazendo com que as mesmas enviem de forma de onda modularizada a identificação única da etiqueta. Os receptores de tais ondas modularizadas, denominados de leitores RFID, decodificam os dados recebidos gerando a informação de presença de etiquetas no campo de ação dos mesmos e logo após tornam o evento disponível para interpretação de um sistema computacionais onde será associada as informações ao portador da etiqueta com o respectivo identificador captado. Logo, RFID é um meio para identificação automatizada em que uma informação é, unicamente relacionada com o objeto físico e está inclusa na mesma classe de tecnologias de Auto-ID, como o código de barras, biometria (identificação por digitais, retina), identificação por voz, e sistemas de reconhecimento ótico de letras (OCR) A História da RFID A história da tecnologia RFID pode ser descrita segundo as indicações em [RfiIdJournal, 2007] e [RfiIdJournal, 2007]. Como diversas das invenções hoje comuns no cotidiano, nasceu para fins militares. Se hoje há tanta sofisticação na comunicação por rádio freqüência, boa parte é devida a, físico escocês responsável pela invenção, em 1935, dos sistemas de RADAR (Radio Detection And Ranging ) britânicos durante a segunda guerra mundial. Na mesma época, foi desenvolvido o primeiro sistema ativo de identificação. Seu funcionamento era bem simples, 18

19 em cada avião britânico foi colocado um transmissor que, quando recebia sinais das estações de radar no solo, transmitia um sinal de volta para identificar que o avião era aliado. Entretanto, a história da tecnologia RFID propriamente dita, começa em 1973, quando Mario W. Cardullo requisitou a primeira patente americana para um sistema ativo de RFID com memória regravável. No mesmo ano, Charles Walton, um empreendedor da Califórnia, recebeu a patente para um sistema passivo, o qual era usado para destravar uma porta sem a ajuda de chaves. Na década de 70, o governo americano também estava trabalhando no desenvolvimento de sistemas de RFID, tais como um sistema de rastreamento de material radioativo para o Energy Department, e de rastreamento de gado, para o Agricultural Department. Até então, as etiquetas usadas eram as de baixa freqüência (LF - Low Frequency), ou seja 125 khz, até que as empresas que comercializavam estes sistemas mudaram para os sistemas de alta freqüência (HF - Low Frequency), de MHz, o qual seu uso era irregular e incomum em várias partes do mundo. Hoje, estes sistemas são usados em diversas aplicações, como controle de acesso, sistemas de pagamento e dispositivo de anti-roubo de carros. No começo dos anos 80, a IBM patenteou os sistemas de Freqüência Ultra Alta (UHF - Ultra High Frequency, possibilitando o uso da RFID para realizar leituras a distâncias superiores a dez metros. Hoje, a IBM não é mais detentora desta patente, que foi vendida, devido a problemas financeiros ainda na década de 90, para a Intermec, uma empresa provedora de códigos de barra. O grande crescimento da tecnologia RFID na frequência de UHF foi em 1999, quando um grupo formado pela Uniform Code Council, EAN Internatinal, Procter & Gamble, e Gillete fundou o Auto-ID Center, no MIT, Massachusetts Institute of Technology, berço de vários avanços tecnológicos. Os professores David Brock e Sanjay Sarma do Auto-ID Center foram os grandes responsáveis em difundir a tecnologia RFID entre as grandes empresas. Inicialmente as etiquetas RFID apenas informavam a identificação do item em que estavam anexadas, formando um banco de dados de itens. Brock e Sarma propuseram que esse banco de dados fosse colocado na Internet, assim os fabricantes ou fornecedores permitiriam aos seus clientes tomarem conhecimento de informações importantes a respeito de seus pedidos de compras. Era possível, por exemplo, saber quando os produtos comprados seriam despachados, bem como a data prevista para entrega. Esta facilidade agilizou e melhorou os processos internos das empresas. Entre 1999 e 2003, o Auto-ID Center cresceu e ganhou apoio de mais de 100 companhias, além do Departamento de Defesa dos Estados Unidos. Nesta mesma época foram abertos laboratórios em vários outros países, que desenvolveram dois protocolos de interface aérea (Classe 1 e Classe 0), o Código Eletrônico de Produto (EPC - Eletronic Product Code), o qual determina um esquema de numeração única de etiquetas RFID, e arquitetura de rede para a associação de RFID na Internet. Em 2003 o Auto-ID Center fechou, repassando suas responsabilidades para o Auto-ID Labs. Em 2004, a instituição EPCglobal ratificou uma segunda geração de padrões, melhorando o caminho para amplas adoções da tecnologia RFID. 19

20 3.1.3 A Arquitetura da tecnologia RFID A arquitetura de identificação por rádio freqüência consiste em leitores e etiquetas. O leitor faz uma requisição para a etiqueta, obtém a informação, e então executa uma ação baseada naquela informação[himanshu Bhatt, 2006a]. Esta ação, no contexto do sistema de informação que a utiliza, desencadeia uma série de eventos em aplicativos que gerenciam tais informações. Nas seções que se seguem, serão abordados os principais componentes da tecnologia RFID, tais como etiquetas e leitores Etiquetas As etiquetas de RFID estão em uma classe de dispositivos de rádio definidos como transponders. Um transponder é uma combinação entre um transmissor e um receptor, o qual é responsável por receber um sinal específico de rádio e automaticamente transmitir uma resposta. Uma simples implementação de um transponder ouve passivamente os sinais de rádio e, de maneira automatizada, responde ao perceber a presença de outro transponder. Sistemas mais complexos podem transmitir uma letra, um dígito, ou um conjunto de caracteres, de volta para o transponder que inicia a transmissão. Além disso, um sistema avançado de transponder pode realizar cálculos ou até um processo de verificação, que incluem rádio transmissão encriptada, a qual evita que pessoas não autorizadas obtenham a informação a ser transmitida. Os transponders utilizados em dispositivos RFID podem ser referidos como etiquetas, etiquetas, chips, ou rótulos. De maneira geral, uma etiqueta de RFID podem conter os seguintes itens: Circuito de codificação e decodificação; Memória; Antena; Fonte de alimentação; Controle de comunicação; ativas, passivas e semi- Ainda assim elas se dividem em três categorias: passivas, que serão detalhadas a seguir. Etiquetas Passivas Etiquetas RFID passivas não contém baterias ou outra fonte de alimentação ativa e por esta razão elas precisam esperar por um sinal emitido a partir de um leitor RFID. A etiqueta contém um circuito sensível capaz de absorver energia da antena do leitor. Para tanto a etiqueta passiva utiliza a propriedade eletromagnética conhecida como campo próximo. Como o próprio nome sugere, o dispositivo (etiqueta) deve estar relativamente perto do leitor para ser ativado. O campo próximo então supre, por curto tempo, energia suficiente para a etiqueta passiva ser capaz de enviar uma resposta. 20

21 Etiquetas Ativas Em contraposição à idéia de recurso de alimentação, as etiquetas RFID ativas têm seus próprios meios de alimentação, isto é, não necessitam de ser alimentadas por um campo próximo gerado pela antena do leitor podendo por conseqüência transmitir e receber a maiores distâncias do que as etiquetas passivas. Etiquetas Semi-passivas As etiquetas semi-passivas possuem bateria para alimentar o seu circuito de memória, porém utilizam o campo próximo para alimentar o circuito de rádio no momento da transmissão e recepção de dados. Propriedades das Etiquetas RFID A proposta de uma etiqueta RFID é essencialmente vincular uma informação a um objeto físico. Para isso, cada etiqueta tem um mecanismo interno para armazenar dados e uma maneira de transmiti-los. Além da divisão das etiquetas em ativas, passivas, e semi-passivas, realiza-se também a classificação quanto aos seguintes aspectos: características físicas, interface aérea, capacidade de processamento e armazenamento. Características físicas Para que as etiquetas de RFID possam ser afixadas em objetos de diferentes formas e tamanhos, elas possuem uma grande variedade de formatos, que podem incluir: Etiquetas em formato de botões e discos em PVC ou plástico. Etiquetas em formato de cartões de crédito; Etiquetas em formato de camadas de papel, também conhecidos como rótulos inteligentes, similar àqueles utilizados pelos códigos de barras; Etiquetas embutidas em objetos comuns como livros, chaves e roupas. As figuras de 3.1 a 3.5 mostram etiquetas RFID de tamanhos e formatos variados. Interface aérea A interface aérea descreve a maneira como a etiqueta se comunica com o leitor. Sabendo-se a interface aérea da etiqueta, pode-se determinar o raio de leitura e identificar os leitores compatíveis com ela. Nos tópicos Frequência de operação e Capacidade armazenamento são descritos os principais atributos que compreendem a definição de interface aérea. Frequência de operação 21

22 Figura 3.1: Etiquetas RFID diversas Figura 3.2: Etiquetas RFID em uma carcaça de plástico 22

23 Figura 3.3: Etiqueta em formato de cartão de crédito (Smart Card) Figura 3.4: Chip RFID embutido em relógios Figura 3.5: Chips RFID em braceletes 23

24 Frequência de operação é a frequência eletromagnética utilizada pela etiqueta para se comunicar ou obter energia. Considerando que o sistema de RFID não deve interferir em transmissões próximas de rádio e televisão, serviços móveis de rádio (polícia, serviços de segurança, indústria), serviços de rádio da marinha e aeronáutica, nem telefones móveis, utilizam-se, em geral, freqüências que foram reservadas especificamente para aplicações industriais, científicas ou médicas como como frequência de operação das etiquetas RFID. Tais freqüências são conhecidas como faixa de freqüência ISM (Industrial-Scientific-Medical). As tabelas 3.1 e 3.2, sumarizam as faixas de freqüências, bem como suas características e aplicações típicas. Nome Raio de frequência Frequência ISM LF 30300kHz < 135kHz HF 330M Hz 6.78M Hz, 13.56M Hz, M Hz, M Hz UHF 300M Hz 3GHz M Hz, 869M Hz, 915M Hz Microondas > 3GHz 2.45GHz, 5.8GHz, GHz Tabela 3.1: Classificação de raios de frequências para dispositivos RFID [Himanshu Bhatt, 2006b]. O raio da leitura em função das freqüências é mostrado na tabela 3.2. Nome Raio de leitura Aplicação LF 50 centímetros Identificação de animais e leitura a curta distância HF 3 metros Controle de acesso a dependências físicas. UHF 9 metros Identificação de caixas e paletes. Microondas > 10 metros Identificação de veículos. Tabela 3.2: Raio máximo de leitura para etiquetas passivas de acordo com a freqüência [Himanshu Bhatt, 2006b]. Capacidade de armazenamento A capacidade de armazenamento também varia de acordo com o tipo de microchip. Algumas etiquetas, mais simples, podem armazenar somente 1 bit, e são utilizadas, por exemplo, em bibliotecas para verificação da situação dos livros que saem de seus recintos. Outras podem armazenar uma quantidade maior de dados, que pode chegar a até 256 kilobytes[himanshu Bhatt, 2006c]. 24

25 Leitor O segundo componente básico de um sistema RFID é chamado de leitor ou interrogador. Figura 3.6: Exemplo de leitor RFID Eles funcionam como transmissores e receptores de sinais de rádio frequência. Estes sinais são espalhados por radiofusão, e são recebidos e transmitidos pelas antenas que são conectadas aos leitores. Através de uma unidade de controle, eles processam as informações/dados enviados e recebidos por radiofusão e, se preciso, os transmite por canais de comunicação, via conexão de rede, serial ou USB, para os middlewares, que são softwares cuja função é desempenhar o papel de gerência de eventos, detecção, leitura e escrita das etiquetas RFID (Figura 3.7). Figura 3.7: Organização lógica de um leitor Middleware Middleware é um software que gerencia os dados capturados das etiquetas pelos leitores e os repassam para um sistema backend de banco de dados. O middleware se localiza entre os leitores e a aplicação cliente, e atua como um elemento encapsulador da interface dos dispositivos leitores de etiquetas. Além disso, ele atua como um filtro de informação, evitando a sobrecarga desnecessária de processamento de informações ao sistema RFID. Não é necessário enviar informações duplicadas acerca de uma etiqueta RFID, bem como alertar a aplicação cliente todo o momento que uma etiqueta estiver no raio de leitura dos interrogadores. 25

26 A figura 3.8 demonstra a visão lógica da arquitetura de um middleware para sistemas RFID: Figura 3.8: Arquitetura de um middleware para sistemas RFID Um middleware para um sistema RFID é composto por três módulos: Interface em nível de aplicação: Interface responsável por prover serviços comuns às aplicações clientes; Gerenciador de eventos: Gerenciador de eventos informados pelos leitores. Atuam como filtros de informações, evitando sobrecarga de dados no sistema; Adaptador do leitor: Camada de adaptação de serviços aos leitores. Esta camada é responsável por encapsular as interfaces proprietárias dos diferentes leitores RFID em uma interface padrão. Com isso, evita-se que os desenvolvedores das aplicações cliente tenham que aprender o funcionamento das diferentes interfaces dos leitores RFID disponíveis no mercado Padrão EPCGlobal A EPCGlobal, Inc. é uma organização sem fins lucrativos criada para controlar, desenvolver e promover padrões baseados na tecnologia RFID. Seu objetivo é orientar a adoção deste sistema como o padrão mundial para a identificação imediata, automática e precisa de qualquer item da cadeia de suprimentos de qualquer empresa, de qualquer setor e em qualquer lugar do mundo. Ela define componentes por meio de documentos de especificações e podem ser implementadas por qualquer linguagem de programação, desde que implemente os serviços definidos nas especificações. Os componentes definidos pela EPCGlobal são: Número EPC: Identificador global e único, utilizado para acessar os dados na rede EPC. Acomoda as informações do GTIN - Identificador Global de Item Comercial, que identifica os produtos no Sistema GS1. Etiqueta EPC: É composta de um componente eletrônico (microchip) que tem o seu número de identificação gravado e um transmissor conectado a uma antena. As etiquetas podem ser confeccionadas em todos os tamanhos e formatos, com espessura tão fina que permite a aplicação na superfície dos produtos. Algumas têm a capacidade adicional de registrar novos dados. 26

27 Leitor de Radiofreqüência: Emite ondas magnéticas que aciona a etiqueta RFID, permitindo que transmita de volta a informação armazenada no micro-chip. Decodifica, verifica, armazena os dados e se comunica com o computador. Savant: Também chamado de EPC middleware, recebe o código pelo leitor, pergunta ao ONS onde encontrar informação sobre um produto, e então busca os dados na rede, conforme definido pelo ONS. Serviço de Nomeação de Objeto (ONS): Bastante semelhante ao Serviço de Nome de Domínio (DNS) da Internet. O serviço ONS traduz números EPC para endereços da Internet. Isso faz com que as consultas de informações baseadas em número EPC sejam remetidas para os bancos de dados que contenham as informações solicitadas. EPCIS: Sistema de informação que mantém todos os dados EPC com regras de acesso, controle, autorização e autenticação. O PML (Physical Markup Language), é o vocabulário definido em XML, que permite a consulta e a obtenção de dados relativos aos números EPC. Nos tópicos a seguir são esclarecidos os componentes definidos pela EPC- Global, com exceção do leitor e middleware, esclarecidos nas seções e respectivamente. Etiquetas do padrão EPCGlobal A EPCGlobal classifica as etiquetas RFID de acordo com as funcionalidades estipuladas, o protocolo de comunicação utilizado e a forma de alimentação das etiquetas. As etiquetas de acordo com este padrão têm a intenção de carregar identificadores únicos chamados de EPC (Eletronic Product Code) os quais são definidos por entidades específicas, que possuem as classes de objetos físicos envolvidos. A tabela 3.3 mostra as diferentes classificações das etiquetas reconhecidas pela ECPGlobal: Classe Classe 0 Classe 1 Classe 2 Classe 3 Classe 4 Classe 5 Descrição Passivas, somente leitura. Passivas, somente leitura e escrita somente única vez. Passivas, de leitura e gravação. Regraváveis, de leitura e gravação com fonte própria de energia. Todas funcionalidades da classe 3 somadas a capacidade de comunicação ativa com leitores e outras etiquetas ativas. Todas funcionalidades da classe 4 somadas a capacidade de comunicação com etiquetas passivas. Conceitualmente leitoras. Tabela 3.3: Classes de etiquetas do padrão EPCGlobal[Himanshu Bhatt, 2005] Código eletrônico de produtos - EPC 27

28 O EPC foi criado pelo Auto-Id Center como o eventual sucessor do código de barras. É o identificador único de uma etiqueta, podendo ser comumente constituído de um número de 64 ou 96 bits. Ele se divide nas seguintes partições: Cabeçalho - descritor do formato do EPC; Código do gerenciador do EPC; Classe de objeto Número de série As primeiras duas propriedades são definidas pela EPCGlobal e as últimas duas pela entidade que gerencia a etiqueta RFID. Linguagem de marcação física - PML(Physical Markup Language) O PML é uma coleção de vocabulários XML padronizados para representar e distribuir informações a objetos relacionados em sistemas de auto-identificação. Ela é dividida em dois módulos: PML Core: Fornece um formato padronizado para troca de dados capturados em sistemas de auto-identificação baseados no EPC. Ela fornece um formato padrão para troca de dados que são capturados por sensores, como leitores de RFID, dentro de uma arquitetura de auto-identificação, fazendo com que mensagens baseadas no esquema PML Core possam ser trocadas entre sistemas em uma rede EPC. Informações como de qual classe de de objeto EPC se refere o item, qual o caminho percorrido pelo EPC ou a qual a data e hora do último evento registrado de um item são exemplos dos dados disponíveis neste módulo. PML Extensions: A PML Extensions fornece extensões especificas que ofereçam suporte as gerenciadoras da etiqueta RFID. Informações de qual a dimensão, o peso, qualidade ou cor do objeto portador da etiqueta são providos por este módulo. Serviços de informação de EPC EPCIS (Serviços de informação de EPC) são serviços que utilizam vocabulários XML padronizados para trocar informações acerca de eventos ou da descrição física dos objetos com o EPC correspondente. São referenciados também como PML Servers ou PML Services. As principais funções do EPCIS são: Representar um repositório que garanta a manutenção a longo prazo da informação recolhida pelos middlewares. Permitir acesso a informação que possa ser derivada dos eventos recolhidos pelos middlewares com outra informação que esteja armazenada em outros sistemas. Permitir o armazenamento e acesso de atributos que estejam definidos ao nível da EPC (por exemplo, data e hora de criação). 28

29 Serviço de nomeação de objetos ONS, serviço de nomeação de objetos, fornece um serviço de busca para traduzir um EPC em uma ou várias URLs(Uniform Resource Locator), assemelhando-se ao DNS (Domain Name System), onde maiores informações sobre o objeto correspondente a etiqueta RFID podem ser encontradas. Os passos a seguir exemplificam este procedimento: 1. Uma sequência de bits contendo um EPC é lida de uma etiqueta RFID: O leitor então transmite a mensagem, através do middleware, para um servidor destinado a converter a seqüência de bits em URI (identificador uniforme de recursos); 3. Depois de convertida a seqüência de bits em um URI, este servidor envia um a requisição ao servidor ONS local a seguinte resolução: urn:epc: ; 4. O servidor ONS converte a URI em identificador de domínio e então passa ao DNS a requisição: unb.br; 5. A rede DNS pesquisa e retorna URL que indica a informação sobre o servidor de EPCIS correspondente; 6. O servidor local ONS obtém a URL do registro DNS e o retorna para o servidor local, cliente do middleware : 7. O servidor local contata o servidor PML correto obtido através da URL para o EPC em questão; Redes RFID Distribuídas Os leitores RFID originalmente são vistos como periféricos que normalmente são conectados a um computador host através de uma porta serial dedicada para responder a um pedido. Este tipo de configuração é conhecido como centrada na aplicação (figura 3.9). Embora esta seja uma abordagem simples de leitores em conexão com o sistema oferecendo as funcionalidades adequadas, a forma de conexão envolve um modesto número de leitores para executar uma função específica direcionada as regras de negócio. Para acomodar implementações de serviços RFID em larga escala, uma nova geração de leitores foi desenvolvido. Estes dispositivos de rede possuem suporte TCP/IP e são conectadas através redes cabeadas (Ethernet ) ou sem fio (802.11). Uma rede de leitores que captura os dados necessários para aplicações cliente RFID, aplicação A e aplicação B por exemplo, através dos middlewares, os quais localizam-se entre os leitores, são definidos como uma rede RFID. Este tipo de configuração de rede é dita ser como centrada na rede, figura Na concepção de uma rede RFID, várias questões que devem ser consideradas afim de satisfazer as necessidades da cobertura de interrogatórios das etiquetas e no compartilhamento das informações dos eventos gerados por estes para as aplicações cliente. Segue-se na próxima seção os elementos que devem ser relevados quando na concepção de redes RFID distribuídas. 29

30 Figura 3.9: Sistema RFID centrado na aplicação Figura 3.10: Sistema RFID centrado na rede. 30

31 Elementos da concepção de redes RFID distribuídas Redes Dedicadas e Amontoadas Todos os objetos exceto para a aplicação RFID A, B e middleware na porção superior da figura 3.10 apresenta os principais componentes de uma rede típica em uma organização, que incluem servidores e clientes que executam diversas aplicações, tais como por exemplo ERP, Inventory Management System (IMS) e um sistema de RH. A banda de rede exigida pelas aplicações varia de organização para organização, e também dependendo da natureza das aplicações. Eles compõem o maior consumo no tráfico da rede e é muito comum que algumas portas dos roteadores centrais e secundários estejam relacionadas com a expansabilidade de nós da rede. Há dois pontos para escolher quando na adição de rede RFID em uma rede existente: amontoada ou dedicada. Na arquitetura amontoada, figura 3.11, a adição de rede RFID (principalmente dos leitores, middleware e as aplicações RFID) irá situar-se no topo da rede, e eles poderão, por exemplo, estar conectados diretamente às portas disponíveis nos switches secundários e principais. Tal arquitetura de rede irá se misturar com a rede da organização e limitar sua escalabilidade. Na arquitetura dedicada, figura 3.12, os leitores RFID são conectados a switches dedicados os quais se conectam aos switches principais. O middleware, também se conecta a este switch, filtra os dados do leitor RFID e converte os dados em informação para que sejam utilizadas pelas aplicações RFID. A aplicação RFID, como um tipo de aplicação da organização, comunica-se com o middleware através de um roteador firewall, que alterna entre a rede RFID por motivos de segurança. Tal arquitetura de rede provê a rede RFID grande escalabilidade e resiliência na restrição gerencial da rede com segmentação. Figura 3.11: Arquitetura amontoada. 31

32 Figura 3.12: Arquitetura dedicada. Se o switch secundário 1 e 2 numa organização são atribuídos para a mesma rede, então os leitores conectados aos switches devem herdar tal segmentação, mesmo que a aplicação RFID precise que os leitores estejam em diferentes redes ou VLANS. Outra característica é que a segurança é tratada como o enorme tráfego. A arquitetura amontoada traz vulnerabilidade dentro da rede da organização. Um hacker pode colocar um número de etiquetas dentro de um campo de interrogação dos leitores conectados ao switch 1, o qual gera um enorme tráfego no segmento da etiqueta até o switch. Se não há nenhuma LAN virtual configurada no switch, então o tráfego de etiquetas irá sobrecarregar a sub-rede do switch, e poderá causar sobrecarga nas aplicações de rede que estão executando na sub-rede do mesmo switch. A escalabilidade é muito confinada na arquitetura amontoada por causa de suas características, em contraste com a arquitetura dedicada, que oferece escalabilidade diversificada na sua implantação. 32

33 Arquitetura Amontoada Dedicada Facilidade Disponibilidade de Disponibilidade de portas nos switches portas no switches e secundários e principal. principal somente. Sub-redes É limitado pela existência de configuração nos switches secundários. Se a rede local virtual não é suportada o tráfego de RFID vai impactar na banda disponível para as aplicações da rede da organização. VLAN Conecta as portas disponíveis para a mesma rede local virtual de RFID (precisa de switches secundários para Tratamento de segurança na sobrecarga de tráfego suportar a VLAN). Vulnerável por causa de restrições da segmentação e a posição do middleware na rede. Escalabilidade Limitado Flexível É limitado pela existência de configuração nos switches secundários. Se a rede local virtual não é suportada o tráfego de RFID vai impactar na banda disponível para as aplicações da rede da organização. Sem restrição. Resiliente para os diversos casos. Tratados por M/W no interior da rede RFID, ou por roteadores do tipo firewall dedicados. Tabela 3.4: Principais características das arquiteturas de rede RFID[Yi Zhi Zhao, 2007]. 33

34 Requisitos específicos da aplicação Imagine, como exemplo, que os revendedores de um varejo pretendam aumentar suas vendas com a utilização da tecnologia RFID principalmente a partir das seguintes perspectivas: inventário no contexto da loja, controle de gestão, balanço rápido com suporte contagem de itens, capacidade de monitorar e rastrear e prevenção de faltas no estoque. É então citado os seguintes conceitos e métodos para atender aos requerimentos desta aplicação RFID: 1) Ponto Cobertura: atribuição de um grupo de leitores para cobrir muitos objetos no chão da sala de vendas. Este método de alocação de leitores atende a dois requisitos da aplicação: contagem rápida de estoque e prateleiras inteligente. As informações de contagem do estoque, como qual e quantos produtos estão atualmente no departamento de vendas, podem ser obtidos em diferentes tipos de granularidades. Para prateleiras inteligentes, quanto o número de objetos nas prateleiras, por exemplo, livros em uma biblioteca e as mercadorias em uma loja de varejo, diminuem em certo nível, que é configurável de acordo com as necessidades da aplicação, o middleware, verificando a situação baseada na cobertura, irá alertar o sistema através de um pedido do produto. 2) Limite de separação: atribuição de dois grupos de leitores ao longo dos limites de duas áreas para construir uma fronteira separação. Suporta a capacidade de monitorar e rastrear com granularidades diferenciadas. 3) Leitores móveis: montando o leitor sobre uma base móvel ao longo da faixa fornece cobertura eficaz em termos de custos de utilização leitor. Número de Leitores O número de leitores RFID em uma rede que pode ser obtido a partir do número de zonas leitura levantada com base na análise do espaço físico. O número de zonas leitura, por sua vez, é determinado pela cobertura interrogação exigida pela aplicação. No processo de determinar o número de leitores, muitas opções para monitorar e rastrear em diversas escalas e cobertura de interrogação das etiquetas devem ser fornecidos para os usuários finais do sistema RFID. Exigência da banda de tráfego na rede RFID Para projetar uma boa relação custo-benefício e uma rede de RFID, é necessário realizar análise quantitativa sobre as exigências da banda de tráfego na rede RFID. O EPC é o número de identificação padronizado de objetos da EPCglobal Network. A EPCGlobal Network fornece um framework flexível para a estrutura dados EPC e suporta vários esquemas de numeração (por exemplo, GTIN, SSCC, GLN, GRAI, GIAI, GID, EAN.UCC; VTN, CAGE) [NetworkTM, 2006]. Os esquemas de numeração podem identificar todos os objetos (etiquetas EPC), na rede EPCGlobal. Ele conecta objetos físicos a uma rede de computadores. O quadro 3.5 mostra uma amostra de um EPC de 96 bits. Assumindo-se que o EPC é a única coisa armazenada no chip, e por conseqüência, é o único dado que é passada da etiqueta para o leitor, o leitor tem 34

35 01 OOOOA F 0001S9DC0 8 bits 28 bits 24 bits 36 bits Cabeçalho Gerente do Classe do objeto Número serial domínio Determina a estrutura Identifica a enti- Representa a Identificação de dados dade responsável classe do objeto única do objeto. da etiqueta. por manter os números subseqüentes Tabela 3.5: Código eletrônico de produtos: EPC a acrescentar sobre outra camada de informações básicas, a fim de atender o middleware, como o a assinatura de hora da leitura e o identificador da antena. Do mesmo modo, middleware também tem a acrescentar mais uma camada de informações básicas para que o seu próprio uso além das aplicações do sistema, como por exemplo a estampa de data e hora do middleware e o identificador do leitor indicando a hora exata que o mesmo recebeu as informações de determinado leitor. Portanto, a largura de banda necessária para o tráfego da etiqueta EPC para cada leitor é calculada em três níveis: etiqueta para o leitor, leitor para o middleware e middleware para a aplicação. 1) Etiqueta para o leitor: BW t = N i=1 (St XAi) Onde St é o tamanho do ID da etiqueta EPC (por exemplo, 96-bit); X ai é o número médio de chegadas evento por segundo para antena i (por exemplo, 600 são limites superiores na Europa); N é o número de antena do leitor ( por exemplo, 4); BW t é a largura de banda necessária para o leitor a obter as informações da etiqueta EPC numa taxa Ai. 2) Leitor para o middleware BW r = BW t + N i=1 (Sts + Sc + Ia)Xai + Sip. Onde Sts é o NTP (Network Time Protocol) de 64 bits, correspondente a string no formato YYYY: MM: DD HH: MM: SS.MS); Alguns leitores fornecem duas estampas de tempo respectivamente para a primeira e última leitura dentro intervalo de tempo. Sc é o tamanho do contador de leituras (8-bit), e Ia é o identificador da antena (8-bit);Sip é tamanho de endereços IP de Origem e destino. BWr é a largura de banda necessária para o middleware obter os dados da etiqueta captada pelo leitor. 3) Middleware para as aplicações: A exigência de banda depende da natureza das aplicações. Em primeiro lugar, para a aplicação que necessita constantemente, alta freqüência, de interrogação das etiquetas(alto valor de ai ), exige banda de rede elevada. Em segundo lugar, o volume de dados potencialmente transmitido através da rede não é apenas um fator do número de etiquetas e comprimento do EPC ID. O padrão EPCGlobal contém um Object Naming Service (ONS), que permite uma etiqueta para especificar o local (endereço IP), de informação sobre os produtos armazenados noutro local na rede [Brown and Wiggers, 2005]. Assim, uma etiqueta pode gerar ou requisitar e recuperação de dados a partir de qualquer ponto da rede. Logo, o tráfego 35

36 nesta camada deve ser quantificado de acordo com a especificação da aplicação Aplicações da tecnologia de identificação por rádio frequência Por conseqüência das vantagens oferecidas na tecnologia RFID, como não requer contato visual, leitura automática e robustez, existe atualmente diversas aplicações da RFID. Ela é usada em todas as áreas que necessitam da captura automática de dados, permitindo a identificação de objetos sem contato físico, via radiofreqüência. Pode-se citar as aplicações em pedágios, aplicações médicas, controle de acesso, proteção pessoal e logística como destacado em[teleco, 2008] RFID na Identificação humana Na área de identificação humana, uma das principais aplicações da tecnologia RFID é no controle de acesso, tanto a prédios como a salas específicas, automatizando a verificação de permissão de acesso. Os sistemas de controle de acesso e autorização podem ser divididos em dois principais grupos: on-line e off-line. Os sistemas on-line são sistemas onde todos os terminais estão conectados a uma central através de uma rede. Este computador central roda um banco de dados, e comunica-se com os terminais para autorizar o não a entrada de determinada etiquetas que está fazendo um requisição. Este tipo de sistema é utilizado, por exemplo, no acesso a prédios comerciais e escritórios. Se alguma alteração no controle de acesso for necessária, esta pode ser feita de maneira mais simples, através do computador central, sem a necessidade da etiqueta estar presente, pois nela contem apenas um número de acesso. Nos sistemas off-line, não há uma comunicação em rede entre os terminais e um computador central, cada terminal contém uma tabela de autorizações. Este tipo de sistema é utilizado onde há muitas salas individuais, as quais poucas pessoas possuem acesso. A etiqueta também contem uma tabela de autorizações onde são armazenados sua permissões, como por exemplo, sala 1, térreo ou depósito. O leitor compara então a sua tabela de autorizações com a da etiqueta, e autoriza ou nega o acesso. A etiqueta é programada em uma central, como a recepção de um hotel ou a seção de uma empresa, com os acessos a que ela tem direito, além de outros dados como, por exemplo, a data de expiração para os acessos. Uma outra aplicação da RFID para identificação humana é nos sistemas de bilhetagem. Um exemplo recente foram os ingressos da Copa do Mundo de 2006, Alemanha, que estavam equipadas com etiquetas RFID, para evitar a falsificação e ação de cambistas. Os microchipes RFID contidos no cartão de ingresso emitem um sinal de rádio que é captado por leitores on-line nas entradas dos estádios[theregister, 2008b]. Na área médica, é a identificação humana através de microchipes implantados tem despertado o interesse de muitos pesquisadores. Em outubro de 2004, a FDA (Food and Drug Administration ), agência que regula o uso de medicamentos e alimentos nos Estados Unidos, liberou o implante de etiquetas em humanos para uso médico[theregister, 2008a]. O VeriChip, com dimensões próximas a 36

37 do grão de arroz, é uma etiqueta do tipo passiva inserida sobre a pele do paciente que contém unicamente um identificador de 16 dígitos. Esta tecnologia permite a identificação imediata do paciente pela equipe médica. Entretanto, um problema levantado muito recentemente diz respeito quanto à segurança destes sistemas. Uma dupla de hackers demonstrou como os chips de RFID implantados em humanos, como os da VeriChip, podem ser clonados e a identidade da pessoa, roubada. Annalee Newitz e Jonathan Westhues fizeram a demonstração na conferência HOPE (Hackers on Planet Earth ) Number Six, em Nova York[theregister, 2008a]. Na área de entretenimento, já existem discotecas como a Baja Beach Club, em Barcelona, na Espanha, que possibilitam o implante de microchipes em seus clientes para que os mesmos tenham acesso diretos aos serviços VIP, tal como pagar suas respectivas contas sem a necessidade de apresentar nenhum documento[gazette, 2008]. Nos eventos esportivos[finkenzeller, 2003a], além da bilhetagem, etiquetas são utilizadas também em corridas, aplicadas no cadarço dos corredores, figura 3.13 para saber com exatidão o tempo percorrido. Este tipo de aplicação torna-se util principalmente em provas onde a quantidade de corredores é muito grande. Figura 3.13: Uma etiqueta afixada em cadarço de tênis de corrida[finkenzeller, 2003b] Computação Ubíqua Apresentação A Computação Ubíqua, também conhecida como Ubicomp ou Computação Invisível, é um paradigma que propõe um modelo de integração entre processamento de dados e atividades cotidianas de modo invísivel ao ser humano, baseando-se na fusão de computadores ao mundo físico de maneira que serviços possam ser prestados por eles de maneira pró-ativa, e contextualizada de acordo com as necessidades apresentadas pelas situações da vida real. No final da década de 1980, Mark Weiser, então Tecnólogo-Chefe do PARC (Palo Alto Research Center), um centro de pesquisa da multinacional norteamericano XEROX, idealizou o conceito de Computação Ubíqua em resposta ao desafio de elaborar um novo paradigma computacional capaz de se tornar uma 37

38 evolução da visão que se tinha do uso do computador e de sua maneira de solucionar problemas cotidianos. Inspirado por questões levantadas por diversas áreas das ciências humanas, como filosofia, antropologia, psicologia, sociologia científica e pelo pensamento pós-modernista, Weiser buscou uma solução que fosse capaz de integrar o processamento de dados às situações e problemas diariamente vividos pelas pessoas, tendo em mente que a compreensão dessas ciências o levaria à tal solução. Os estudos pesquisados por Weiser o levaram à perceber que, mais do que uma ferramenta de trabalho, que deveria ser invisível ao usuário, o computador se torna freqüentemente um foco de atenção, e, por vezes, um obstáculo a esse trabalho ([Mark Weiser, 1993]). Baseado nessas questões, em 1988 Mark Weiser e vários de seus companheiros do PARC elaboraram as primeiras idéias e os primeiros artigos sobre Computação Ubíqua, que conferiram à eles (e a Weiser principalmente) o status de pais da Ubicomp. A Computação Ubíqua tem, portanto, como cenário ideal, um determinado ambiente físico em que um ou mais elementos, através do uso de computadores de tamanho, formato e capacidade de processamento adequados a cada um, sejam capazes de prestar serviços convenientes ao ser humano sem que este tenha que requisitá-los, ou mesmo tome conhecimento de quem os fornece. Para tanto, é indispensável que esses elementos sejam capazes de avaliar, pró-ativamente, o momento em que se tornam necessários, de comunicar-se entre si quando assim for devido, e de responder adequadamente de maneira que o processamento por trás da tarefa realizada seja invisível para o cliente. Em suma, é necessário que o computador cumpra tarefas do dia-a-dia sem que seja notado como meio de consecução dessas tarefas, assim como na maior parte do tempo não atentamos para os óculos como o meio pelo qual enxergamos com nitidez, ou paredes como o meio pelo qual nos protegemos de um dia chuvoso. Nesse contexto da tecnologia RFID surge como importante aliado na computação ubíqua, pois diminui o espaço entre a monitoração real dos objetos e o processamento de informações acerca do portador, dado que é possível identificar a etiqueta utilizada, por possuir uma numeração única, e o lugar onde a etiqueta foi lida. Como uma aplicação ubíqua é sensível contexto em que está inserida, isto é, seu comportamento é influenciado por outros dispositivos ubíquos presentes e a presença do homem, identificar a presença dos mesmos através de sensores RFID têm se mostrado ferramenta ideal para computação ubíqua pois de forma automática difere cada dispositivo ubíquo ou ser humano presente no contexto. [Weiser, 1996] apresenta a Ubicomp como a terceira geração de paradigmas computacionais. A primeira geração é apresentada por ele como a era dos Mainframes, em que o processamento de dados era centralizado por máquinas de grande porte que executavam inúmeras tarefas simultaneamente, atendendo a incontáveis usuários. A miniaturização dos processadores, memórias e de diversos outros componentes eletrônicos utilizados no computador trouxe consigo a segunda geração de paradigmas computacionais, a era do PC, o computador pessoal, que levou o computador das grandes empresas e universidades para as casas dos cidadãos comuns, individualizando o seu uso. A terceira geração, a Computação Ubíqua, propõe expandir ainda mais o horizonte dos computadores, e torná-los comuns não apenas nos locais de trabalho e escrivaninhas das residências, mas em todo lugar onde o esforço humano é demandado, e nos objetos mais triviais, como 38

39 canetas, roupas, relógios, portas e cadeiras. A miniaturização do computador e a diminuição dos custos de seus componentes permitiu que sua utilização, originalmente restrita à aplicações científicas ou militares, para realização de cálculos extremamente complexos, fosse expandida para tarefas simples como escrever textos ou ouvir música. A proposta da Ubicomp é que essa miniaturização continue, de modo a permitir que junto com ela se expandam os horizontes de aplicação dos computadores, permitindo que não apenas um, dois, ou três computadores atendam simultaneamente um indivíduo, mas tantos quantos forem necessários para realizar as tarefas que ele precisa que sejam realizadas, e para aumentar seu conforto dentro de um ambiente. Para que esses horizontes sejam expandidos, porém, é necessário que os computadores possam ser aplicados à tarefas mais básicas, nas quais não é conveniente que o homem tenha que interagir diretamente com um computador (nesse caso, a atual geração de desktops já é capaz de suprir a maior parte das necessidades), e que sejam altamente especializadas. Da mesma maneira que os mainframes ainda são vastamente utilizados para execução de processamentos muito complexos e manipulação de grande volume de dados (como em instituições bancárias ou estudos científicos), mas tiveram seu uso muito diminuído com a popularização dos desktops (que assumiram antigas funções dos mainframes além de gerar muitas novas aplicações) a idéia por trás da Ubicomp não é substituir desktops ou mainframes totalmente, mas apenas onde sua utilização for mais conveniente, e permitir o alcance do computador aonde as tecnologias correntes não são aplicáveis. Um exemplo de ambiente ubíquo pode ser verificado em [Mark Weiser, 1993]. Nesse artigo, os autores descrevem a utilização de sensores de localização (que utilizam a tecnologia RFID, a ser descrita mais adiante neste trabalho) para monitorar os movimentos de visitantes voluntários dentro de um museu na cidade de Osaka, no Japão. Esses sensores localizam os voluntários através de uma pulseira utilizada por eles, com uma etiqueta de localização. A partir dos dados coletados por esses sensores, é feita uma avaliação por um programa de computador, baseada no percurso feito pelo visitante no museu e nos seus dados pessoais, de suas áreas de interesse. Essa avaliação é utilizada por robôs espalhados pelo museu para interagir com os visitantes de acordo com seu perfil pessoal, localizando-os através de outros sensores embutidos nos próprios robôs, endereçando-os pessoalmente e orientando-os ou entretendo-os de acordo com suas preferências. Desta maneira, os visitantes que se voluntariaram interagiram com os robôs sem que notassem o uso do computador como intermediário, já que as pulseiras não atraíam a atenção desses voluntários; os robôs, por sua vez, prestaram um serviço personalizado aos visitantes do museu, captando dinamicamente as necessidades de cada um, através da localização por sensores ubíquos [Kanda, 2007] Computação Móvel, Computação Pervasiva e Computação Ubíqua A Computação Ubíqua possui uma forte relação com outras áreas de pesquisa: a Computação Móvel e a Computação Pervasiva. De fato, elas são por vezes confundidas entre si, e é comum que a Computação Ubíqua seja chamada de pervasiva ou móvel. Existem, porém, diferenças entre esses conceitos, conforme [de Araújo, 2003]: 39

40 Computação Móvel A Computação Móvel tem por princípio garantir que um determinado dispositivo computacional possa ser movido fisicamente de um ponto A para um ponto B sem que perca suas funcionalidades. É a tecnologia aplicada em notebooks e telefones celulares, por exemplo, e, aliada à popularização do acesso wireless à internet, é capaz hoje de permitir que computadores sejam deslocados por grandes distâncias e ainda assim possam ser utilizados plenamente. A Computação Móvel tem por limitação o fato de não permitir uma reconfiguração dinâmica do contexto em que se encontra, por questões de segurança e limitação de hardware. Além disso, a Computação Móvel compartilha alguns obstáculos com a Computação Ubíqua, a se destacar as limitações atuais nas tecnologias de baterias e outras fontes de alimentação de energia. Computação Pervasiva A Computação Pervasiva é baseada na capacidade de um computador de interagir com o ambiente à sua volta, e dele retirar informações que permitam reconfigurar dinamicamente uma aplicação que ele execute ou outro dispositivo que esteja inserido nesse ambiente, de modo a ajustar o serviço prestado para um determinado usuário. Essa propriedade é o que permite a pró-atividade e a adaptabilidade de um computador em um determinado ambiente, e é o que torna um computador pervasivo inteligente. Segundo os fundamentos da Computação Pervasiva, é fundamental também que um computador seja capaz de identificar outros computadores dentro de seu raio de atuação. Computação Ubíqua A Computação Ubíqua é nada mais que uma combinação da Computação Móvel com a Computação Pervasiva. Assim sendo, o objetivo da Computação Ubíqua é aliar a capacidade da Computação Pervasiva de integrar dinamicamente diversos dispositivos em um determinado ambiente à capacidade da Computação Móvel de permitir o deslocamento desses dispositivos pelo espaço. É importante destacar que num ambiente ubíquo nem sempre é necessário que um dispositivo seja móvel, mas é fundamental que seja pervasivo. Uma lâmpada que acende automaticamente de acordo com a chegada de uma pessoa na sala não é móvel, por que não há necessidade de que se mova, mas é ubíqua por interagir com o ambiente e fornecer um serviço adequado para o usuário. Um dispositivo que não interage com o ambiente, porém, e cumpre sua função de maneira pré-estabelecida e constante, ainda que a cumpra sem ressalvas, não pode ser considerado ubíquo. Outro conceito fundamental para a Computação Ubíqua e Pervasiva é o conceito de Smart Spaces, os espaços inteligentes, que tem por objetivo integrar espaços físicos à computadores. Um exemplo de Smart Space seria uma determinada sala onde a iluminação se regulasse automaticamente de acordo com a presença de uma pessoa no ambiente, ou com o fato de uma TV estar ligada ou desligada, ou ainda com a posição do usuário na sala. Por fim, a confusão entre os conceitos de Computação Móvel, Pervasiva e Ubíqua é devida à pouca idade da Ubicomp como área de pesquisa, e tende a 40

41 diminuir à medida que essa pesquisa evolui com o tempo. Figura 3.14: Comparação entre os paradigmas computacionais. 41

42 Figura 3.15: A Computação Ubíqua é uma interseção entre os modelos das Computações Móvel e Pervasiva. 42

43 Capítulo 4 Sistema de controle e monitoração de acesso: I-Locate Neste capítulo é apresentado uma proposta para a motivação apontada no capítulo 2, o sistema I-Locate. Nas seções que se seguem é apresentada a ordem em que a proposta é desenvolvida e compreende a modelagem de negócio do sistema, arquitetura do software e apresentação do software. 4.1 Processos de negócio existentes na instituição O objetivo desta seção é apresentar elementos suficientes para o entendimento dos atuais processos de negócios relacionados ao controle e a monitoração dos usuários que acessam as dependências físicas do HUB. Tais informações foram obtidas por meio de entrevistas, realizados com a equipe da segurança do HUB. Atualmente, no controle de entrada, saída e deslocamento do usuário na dependências físicas do hospital são empregados três processos de negócios: 1. Registrar entrada do usuário: é necessário que o interessado dirija-se a algum ponto de entrada. Neste ponto de entrada, o interessado deve identificarse com algum documento de identificação válido, tais como: Identidades expedidas por órgãos oficiais, identidade funcional ou carteira estudantil da Universidade de Brasília. Após a identificação pessoal do interessado, define-se o tipo do mesmo de acordo com a finalidade de sua entrada. Os tipos se interessados podem ser: Visitante de pacientes; Acompanhante de paciente; Paciente; Funcionário; Usuário casual; Após são analisadas as seguintes regras de negócio para cada modalidade de interessado: 43

44 Visitante de paciente Se o interessado for um visitante de pacientes, então é liberado o acesso de acordo com o horário de visitas das 15:00 as 16:00, de Segunda a Sexta; Se o interessado for um visitante para um paciente conveniado, então terá o acesso liberado caso o número de visitantes naquele momento para o paciente for menor do que 2; Se o interessado for um visitante para um paciente não-conveniado, então o acesso será liberado caso o número de visitantes naquele momento para o mesmo paciente for menor do que 1; Acompanhante de paciente - O acesso de acompanhante de pacientes pode ser realizado a qualquer hora e dia restringindo-se a um acompanhante por paciente; Paciente - Este têm seu acesso às dependências do hospital através de ordem médica; Funcionário - Estes têm acesso liberado em qualquer dia da semana e em qualquer horário sem a necessidade do registro de entrada, desde que portem a identidade funcional; Usuário casual - Este têm acesso liberado somente com a autorização um funcionário do HUB; Caso o interessado seja liberado para o acesso é efetivado o registro de entrada. Neste passo são registrados em uma ata dados como nome, telefone, endereço, número da identidade, lugar de destino, horário de entrada. Após, é cedido uma etiqueta adesiva as cores das etiquetas são utilizadas, para cada unidade, da seguinte forma: Unidade I Verde: Visitante de paciente; Vermelho: Troca de acompanhante; Amarelo: Todos os outros tipos de interessados; Unidade II Azul: visitante; Vermelho: Qualquer outro interessado; Para melhor entendimento do funcionamento das decisões envolvidas na autorização de acesso de usuários às dependências físicas do HUB, considere os diagramas de atividades nns figuras 4.1, 4.2 e Monitorar usuários Na parte da monitoração, o controle é feito pelo contato visual dos agentes de segurança com a cor da etiqueta. Ás 18:00 horas não é permitido a permanência de uma pessoa portando a etiqueta verde na Unidade 1, pois 44

45 Figura 4.1: Diagrama de atividade do cadastro de entrada do usuário do tipo visistante. Figura 4.2: Diagrama de atividade do cadastro de entrada do usuário do tipo acompanhante. Figura 4.3: Diagrama de atividade do cadastro de entrada do usuário casual. 45

46 o horário de visitas encerra as 16:00. Esta atividade é bastante onerosa para a equipe de segurança, pois necessita de pelo menos um agente para monitorar cada dependência física. A monitoração deve obedecer as seguintes regras de negócio: Se não for de 15:00 as 16:00 do dia corrente então o visitante deve ser retirado do HUB; Se o interessado portador da etiqueta estiver em dependência não autorizada, então o mesmo deve ser levado para a respectiva área autorizada ou para fora do hospital; 3. Registrar saída de usuários O usuário deve devolver ao segurança a etiqueta adesiva por ele utilizada e seu horário de saída é registrado na ata. Com as informações colhidas com estas entrevistas, foi possível elaborar um diagrama de fluxo de dados de nível 0, apresentado na figura 4.4, o qual fornece a visão estruturada das funções do atual sistema e as entidades de negócio relacionadas com as respectivas funções. Figura 4.4: Diagrama de fluxo de dados 46

47 4.2 Necessidades do sistema Introdução Com base nas informações expostas na seção 4.1, propõe-se um sistema informatizado que utilize a tecnologia RFID, com o objetivo de implementar as regras de negócio existentes, além de oferecer vantagens e facilidades em seu emprego. Quando na tentativa de adentrar no hospital o interessado deve identificarse com algum documento de identificação válido e o sistema deve decidir, com base nas regras de negócio existentes, se o usuário terá ou não permissão para prosseguir nas dependências físicas do hospital. Caso positivo será cedida ao usuário um crachá,com uma etiqueta RFID anexada, e deverá ser devolvido na saída. O sistema deverá registrar a entrada do usuário, os locais e horários por onde o mesmo transita durante sua permanência, além da saída do mesmo. Este monitoramento será realizado através do emprego de elementos de uma rede RFID, ou seja uma rede capaz de capturar sinais da etiquetas anexadas aos crachás portados pelos usuários que passam nas proximidades dos leitores RFID. Este dados permitirão ao sistema identificar acessos e permanências não autorizadas, tanto no que se refere a localização como no horário irregulares. O uso dos crachás e o registro de acesso deverão ser obrigatório para todo e qualquer tipo de interessado que adentrar as dependências do hospital, salvo no caso do mesmo ser funcionário identificado do HUB, sendo para este o uso e registro opcionais. Acerca da monitoração, esta deverá apresentar uma interface gráfica para localização visual do usuário do HUB nas plantas do hospital. Ainda assim, a monitoração deverá agir de forma proativa, isto é, informar ao usuário do sistema acerca da irregularidade do usuário do HUB; Além disso, o sistema deverá: Ser desenvolvido na plataforma WEB: um serviço acessado através de um explorador de internet. Tal característica visa facilitar o seu acesso quanto a restrição física e a portabilidade do mesmo quanto a plataforma do computador cliente utilizado; Ter acesso restrito, isto é, somente usuários com autorização poderão utilizar o serviço; Prover serviços de gerenciamento de informações - prática sistemática de criação, atualização, remoção e pesquisa de registros na base de dados, de usuários que entram no hospital, usuários que utilizam o sistema, leitores RFID, etiquetas RFID, registros de eventos de acesso monitorados e configurações relevantes do middware e o EPCIS utilizados na rede RFID; Utilizar-se de programas de código aberto para tornar o sistema isento de pagamento por uso de softwares externos; 47

48 4.2.2 Requisitos funcionais Esta seção visa formalizar e esclarecer as necessidades do sistema através da utilização de diagramas de caso de uso refletindo os requisitos funcionais do mesmo. Os diagramas representados nas figuras 4.5 a 4.10 descrevem o uso das funcionalidades do sistema segundo ponto de vista de cada ator do sistema, os quais são descritos de modo sucinto abaixo. Usuário do sistema: Usuário genérico do sistema (figura 4.5); Gerenciador de etiquetas RFID: Usuário cuja finalidade é de gerenciar informações acerca de etiquetas RFID no sistema (Figura 4.6). Funcionário da segurança HUB: Usuário cuja finalidade é de controlar o acesso as dependências físicas autorizando ao negando o acesso dos usuários interessados ao do hospital (Figura 4.7). Supervisor da equipe de segurança do HUB: Usuário supervisor da equipe de segurança do hospital (Figura 4.8). Suporte técnico do sistema: Usuário que provê suporte técnico ao sistema e está intimamente ligado a gerenciar configurações para o correto funcionamento do sistema (Figura 4.9). Gestor do sistema: Responsável por gerir os usuários e seus respectivos perfis de acesso ao sistema (Figura 4.10). Figura 4.5: Diagrama do caso de uso do ator usuário genérico. 48

49 Figura 4.6: Diagrama do caso de uso do ator gerenciador de etiquetas. Figura 4.7: Diagrama do caso de uso do ator funcionário da segurança. 49

50 Figura 4.8: Diagrama do caso de uso do ator supervisor da segurança. Figura 4.9: Diagrama do caso de uso do ator suporte técnico do sistema. 50

51 Figura 4.10: Diagrama do caso de uso do ator gestor do sistema. A seguir são descritos detalhes as funcionalidades do sistema para cada ator envolvido. Usuário do sistema Descrição do ator: Qualquer usuário do sistema será representado por este ator, pois os outros atores do sistema extemdem os comportamentos deste ator como mostrado na Figura

52 Nome do caso de uso Objetivo Fluxo principal Autenticar no sistema Autenticar o usuário no sistema para o sistema tenha acesso restrito e seja feito o controle de funcionalidades disponíveis no sistema de acordo com os perfis prédefinidos para o ator: - ILOC100: Gerenciador de etiquetas pré-cadastradas. - ILOC200: Funcionário genérico da segurança do hospital. - ILOC300: Supervisor da segurança. - ILOC400: Suporte técnico do sistema. - ILOC500: Gestor do sistema. 1. Ator insere o login e a senha; 2. Sistema valida os dados inseridos se os dados estiverem corretos e se o usuário está com o perfil ativo no sistema; 3. Sistema redireciona usuário para página de serviços do sistema; Nome do caso de uso Objetivo Fluxo principal Alterar senha de acesso Alterar a senha do usuário do sistema; 1. Ator insere login, senha atual, nova senha e a confimação para a nova senha; 2. Sistema valida os dados de entrada e altera a senha do usuário; Gerenciador de etiquetas RFID Descrição do ator: Pessoa responsável por manter informações no sistema acerca das etiquetas utilizadas no processo de controle e monitoração de usuários que adentram no HUB, já que o sistema somente irá monitorar etiquetas previamente registradas por este ator. 52

53 Nome do caso de uso Objetivo Fluxo principal Incluir registro de etiqueta Inserir informações de uma nova etiqueta no sistema; 1. Ator insere informações sobre a etiqueta: código EPC, marca, modelo; 2. O sistema grava as informações caso o código EPC da etiqueta não existir e se nenhum dos campos informados não estiver em branco; Nome do caso de uso Objetivo Fluxo principal Pesquisar registro de etiquetas Pesquisar registros de etiquetas que estão cadastradas no sistema. 1. Ator insere informações sobre a etiqueta: código EPC, marca, modelo ou código do sistema da etiqueta; 2. Sistema pesquisa todas as etiquetas que possuam as características inseridas; Nome do caso de uso Atualizar registro de etiqueta Objetivo Atualizar informações de etiquetas previamente cadastradas no sistema. Fluxo principal 1. Ator pesquisa a etiqueta a ser atualizada; 2. Ator altera o código EPC, marca ou modelo da etiqueta; 3. Sistema registra as alterações somente se nenhum dos campos está em branco; 53

54 Nome do caso de uso Objetivo Fluxo principal Remover registro de etiqueta Excluir um registro de etiqueta previamente cadastrado no sistema. Observação: Só será possível realizar este caso de uso caso o registro da etiqueta não estiver sendo utilizado pelo sistema, isto é, não possuir dependência com outros registros no sistema. 1. Ator pesquisa a etiqueta a ser removida; 2. Ator seleciona a etiqueta a ser removida; 3. Ator indica ao sistema para remover a etiqueta; 4. Sistema remove a etiqueta caso esta não possua registros relacionados com o registro de acesso de usuários gravados até o momento da exclusão; Funcionário da segurança HUB Descrição do ator: Usuário cuja finalidade é de controlar o acesso as dependências físicas autorizando, denegando o acesso físico dos usuários interessados ao HUB. Nome do caso de uso Objetivo Fluxo principal Incluir interessado Incluir informações de identificação do usuário interessado no sistema. 1. Ator insere informações sobre o interessado de acordo com o tipo de interessado: -Usuário casual: O nome, sobrenome, idade, sexo, código da identificação e tipo de identificação; -Funcionário: O nome, sobrenome, idade, sexo, código da identificação, tipo de identificação e telefone; -Paciente: O nome, sobrenome, idade, sexo, código da identificação, tipo de identificação e se o paciente possui convênio com o HUB; 2. O sistema registra as informações caso não exista registro de usuário interessado com o mesmo código de identificação e tipo de identificação; 54

55 Nome do caso de uso Objetivo Fluxo principal Pesquisar interessados Pesquisar usuário interessados existentes no sistema. 1. O ator insere para cada tipo de usuário: - Usuário casual: o nome, sobrenome, idade, sexo, código da identificação ou o tipo de identificação; - Funcionário: O nome, sobrenome, idade, sexo, código da identificação, tipo de identificação ou o telefone; - Paciente: O nome, sobrenome, idade, sexo, código da identificação e se o paciente possui convênio com o HUB; 2. O sistema pesquisa todos os registros de usuários que satisfaçam os critérios de consulta; Nome do caso de uso Objetivo Fluxo principal Atualizar dados do interessado Atualizar as informações de usuários interessados no sistema. 1. O ator pesquisa o usuário cujos dados serão atualizados; 2. O ator seleciona o usuário a ser atualizado; 3. O ator modifica os dados do usuário conforme o tipo: - Usuário casual: o nome, sobrenome, idade, sexo, código da identificação ou o tipo de identificação; - Funcionário: O nome, sobrenome, idade, sexo, código da identificação, tipo de identificação ou o telefone; - Paciente: O nome, sobrenome, idade, sexo, código da identificação e se o paciente possui convênio com o HUB; 4. O sistema atualiza os dados do usuário caso nenhum dos campos for vazio; 55

56 Nome do caso de uso Objetivo Fluxo principal Excluir interessado Excluir registro de interessados do sistema. Observação: Só será possível realizar este caso de uso caso o registro do usuário interessado não estiver sendo utilizado pelo sistema, isto é, não possuir dependência com outros registros no sistema. 1. O ator pesquisa o usuário cujos dados serão excluídos; 2. O ator seleciona o usuário a ser excluído; 3. O Ator indica ao sistema para remover o usuário selecionado; 4. O sistema remove o usuário indicado caso o usuário não possua nenhum registro de acesso até o momento da exclusão; Nome do caso de uso Objetivo Fluxo principal Monitorar usuários Monitorar localização e regularidade dos usuários que têm o registro de acesso aberto no HUB. A irregularidade deverá ser refletida graficamente nas dependências físicas não autorizadas ou horário de saída vencido; 1. O ator insere a unidade e o andar a ser monitorado; 2. O sistema exibe em forma de ícones os usuários atualmente nas dependências do hospital que portam a etiqueta RFID; 3. O sistema alerta ao usuário do sistema caso algum ícone esteja fora da dependência ou horário autorizado; 56

57 Nome do caso de uso Objetivo Fluxo principal Consultar localização de usuário Consulta a atual localização física do usuário no HUB. 1. O ator insere os dados de registro de acesso para pesquisa de registros de acesso em aberto: ID do registro de acesso, código de sistema da etiqueta que o usuário porta ou código de identificação e tipo de identificação do usuário do HUB; 2. O sistema retorna uma lista de todos os registros de acesso em aberto que satisfaçam os critérios de consulta; 3. O ator seleciona o registro de acesso para qual deseja localizar o usuário; 4. O sistema exibe na forma de ícone a localização atual do usuário na planta do HUB; 57

58 Nome do caso de uso Registrar entrada de interessados Objetivo Registrar o acesso do interessado. O registro de acesso colhe informações de identificação do usuário do HUB, as dependências físicas autorizadas, o horário estipulado para saída, o código da etiqueta RFID utilizada e informações adicionais que variam de para o tipo de usuário. A partir desta funcionalidade o sistema irá começar a registrar os eventos de monitoração nas localizações em que a etiqueta for detectada. Fluxo principal 1. O ator insere o código de sistema da etiqueta que o interessado irá portar se for autorizado a entrar; 2. O ator pesquisa o tipo de interessado para adentrar no hospital que poderá ser: - Usuário casual: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação e tipo de identificação; - Acompanhante de pacientes: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação e tipo de identificação; - Visitante de paciente: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação e tipo de identificação; - Funcionário: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação e tipo de identificação e telefone; - Paciente: pesquisa pelo nome, sobrenome, idade, sexo, código de identificação, tipo de identificação e o estado de convênio; 3. O ator escolhe as dependências físicas autorizadas que o interessado poderá transitar; 4. O ator insere o horário e data prevista para saída do interessado; 5. O ator insere as observações que julgar necessária acerca do registro de acesso; 58

59 Fluxo principal (Cont.) 6. O sistema valida os dados de entrada, isto é, verifica se são verdadeiros caso o interessado seja: - Paciente: verifica se o nome, sobrenome, idade, sexo código da identificação e tipo de identificação não são vazios e se são verossímeis; - Funcionário: verifica se o nome, sobrenome, idade, sexo, código da identificação e tipo de identificação não são vazios e se são verossímeis; - Usuário casual: verifica se o nome, sobrenome, idade, sexo, código da identificação e tipo de identificação não são vazios e se os dados do funcionário autorizante e do usuário casual são verossímeis; - Acompanhante de paciente: verifica se existe algum acompanhante com o paciente indicado e se os dados do paciente a ser acompanhado existem e se são verossímeis; - Visitante de paciente: verifica que o número de visitante para o paciente em questão não é o máximo e se os dados do visitante são verossímeis; 7. O sistema registra os dados inseridos. Nome do caso de uso Objetivo Fluxo principal Encerrar registro de acesso Registrar o encerramento do registro de acesso do usuário nas dependências físicas do HUB, o qual deverá ser feito na saída do usuário do HUB. A partir dessa funcionalidade o sistema não irá mais monitorar a etiqueta em questão. 1. O ator insere o código de identificação do sistema da etiqueta; 2. O sistema pesquisa os registros que contém o código de etiqueta em questão e se existem registros em aberto para a mesma; 3. O sistema retorna os dados do registro de acesso gravados na entrada do usuário interessado; 4. O ator encerra o registro de acesso; 59

60 Nome do caso de uso Objetivo Fluxo principal Consultar registro de interessado existente Pesquisar usuários interessados registrados no sistema. 1. O ator insere os dados do usuário interessado, os quais variam para o tipo de interessado: 2. Usuário casual: o nome, sobrenome, idade, sexo, código da identificação ou o tipo de identificação; 3. Funcionário: O nome, sobrenome, idade, sexo, código da identificação, tipo de identificação ou o telefone; 4. Paciente: O nome, sobrenome, idade, sexo, código da identificação e se o paciente possui convênio com o HUB; 5. O sistema pesquisa o usuário interessado cujos registros satisfaçam os critérios de consulta; 6. O sistema exibe o resultado da consulta; Supervisor da equipe de segurança do HUB Descrição do ator: Usuário supervisor da equipe de segurança do hospital cuja finalidade é de auditar os registros de monitoração quanto a regularidade da localização e horário dos portadores das etiquetas. Nome do caso de uso Objetivo Fluxo principal Consultar relatório de monitoração Pesquisa os registros de monitoração de etiquetas no HUB. 1. O ator insere os critérios de consulta: data de início da monitoração, data do fim da monitoração, número do código de sistema da etiqueta, regularidade da ocorrência do evento de monitoração, ou a dependência física em que ocorreu a monitoração. 2. O sistema pesquisa os registros de acesso que satisfaçam os critérios de consulta; 3. O sistema exibe resultado da consulta; Suporte técnico do sistema 60

61 Descrição do ator: Responsável por realizar suporte técnico do sistema. Este ator é responsável pelas configurações do middleware, EPCIS e do módulo WEB do sistema que o tornam funcional na íntegra. Nome do caso de uso Objetivo Fluxo principal Consultar todos os leitores físicos Consultar todos os leitores físicos registrados no middleware. Observação: Entende-se por leitores físicos, os leitores RFID fisicamente localizados nas dependências físicas do HUB e se conectam ao middleware utilizando-se a rede. 1. O sistema exibe todos os leitores físicos existentes em uma tabela assim como as seguintes informações: Marca do leitor, modelo do leitor, endereço IP do leitor e o nome do leitor; Nome do caso de uso Objetivo Fluxo principal Incluir leitor físico Incluir um novo leitor físico cujos seus os eventos serão gerenciados pelo middleware. Observação: Entende-se por leitores físicos, os leitores RFID fisicamente localizados nas dependências físicas do HUB e se conectam ao middleware 1. O ator insere informações do leitor físico: Marca do leitor, modelo do leitor, endereço IP do leitor e o nome do leitor; 2. O sistema registra o leitor na base de dados; Nome do caso de uso Objetivo Fluxo principal Remover leitor físico Remover um leitor físico previamente cadastrado no middleware. Observação: Entende-se por leitores físicos, os leitores RFID fisicamente localizados nas dependências físicas do HUB e se conectam ao middleware 1. O ator insere o nome do leitor físico; 2. O sistema remove o leitor físico da base de dados; 61

62 Nome do caso de uso Objetivo Fluxo principal Conectar leitor físico com leitor lógico Conectar um leitor físico a um leitor lógico. Esta conexão é necessária para agrupar todos os leitores físicos com o mesmo sentido de negócio em um só leitor lógico. O leitor lógico por sua vez é configurado no middleware RFID do sistema. 1. O ator insere o nome do leitor físico e o nome do leitor lógico existente para o qual o leitor físico fará parte; 2. O sistema conecta o leitor físico ao leitor lógico; Nome do caso de uso Objetivo Fluxo principal Desconectar leitor físico com leitor lógico Desconecta um leitor físico de um leitor lógico. 1. O ator insere o nome do leitor físico e o nome do leitor lógico existente para o qual o leitor físico faz parte; 2. O sistema separa a ligações do leitor físico do leitor lógico; Nome do caso de uso Objetivo Fluxo principal Incluir leitor lógico Incluir um leitor lógico no sistema e relaciona-lo com uma dependência física. 1. O ator insere a identificação do leitor lógico e a dependência física que o leitor representará; 2. O sistema atualiza as informações na base de dados; 62

63 Nome do caso de uso Objetivo Fluxo principal Excluir leitor lógico Excluir um leitor lógico do sistema e suas ligações com a dependência física e os leitores físicos relacionados. 1. O ator insere a identificação do leitor lógico a ser excluído; 2. O sistema remove o leitor lógico da base de dados; Nome do caso de uso Objetivo Fluxo principal Pesquisar todos os leitores lógicos Pesquisar todos os leitores lógicos existentes no sistema e suas respectivas ligações com as dependências físicas. 1. O sistema pesquisa todos os leitores lógicos existentes no middleware. 2. O sistema exibe todos os leitores lógicos encontrados bem como a sua respectiva dependência e os leitores físicos conectados a ele; Nome do caso de uso Objetivo Fluxo principal Pesquisar todas as especificações de relatórios de eventos no middleware. Pesquisar todos os relatórios de eventos de etiquetas registrados no middleware. Estes relatórios definem quais dados serão enviados ao cliente inscrito quando uma etiqueta for detectada pelo leitor lógico. 1. O sistema insere todas as especificações de relatórios que o middleware está destinado a gerar quando alguma etiqueta for detectada pelos leitores físicos; 2. O sistema exibe todas as especificações encontradas, bem o respectivo arquivo XML definindo a mesma; 63

64 Nome do caso de uso Objetivo Fluxo principal Pesquisar hosts inscritos para recepção de relatórios do middleware Pesquisar os hosts inscritos para receberem os relatórios definidos segundo a especificação dos relatórios do middleware. 1. O sistema pesquisa o hosts inscritos para recepção de relatórios de eventos do middleware; 2. O sistema exibe as informações na tela; Nome do caso de uso Objetivo Fluxo principal Pesquisar nó de conexões do middleware para envio de eventos Mostrar de maneira gráfica as conexões dos leitores físicos para o lógico e do lógico para os hosts inscritos a receberem informações acerca de eventos gerados pelo leitor físico definido na especificação de relatório. 1. O sistema pesquisa informações acerca de conexões entre os leitores físicos, leitores lógicos, especificações de eventos do middleware e o host de destino para cada relatório; 2. O sistema existe as informações da pesquisa; Nome do caso de uso Objetivo Fluxo principal Pesquisar etiquetas monitoradas pelo sistema Pesquisar os últimos eventos gerados pelas presenças das etiquetas nas dependências físicas do HUB. 1. O sistema pesquisa os últimos eventos de etiquetas monitoradas detectada pelo sistema; 2. O sistema exibe as informações na tela; Gestor do sistema Descrição do ator: Responsável por gerir os usuários e seus respectivos perfis de acesso ao sistema. 64

65 Nome do caso de uso Objetivo Fluxo principal Incluir usuário de sistema Incluir um novo usuário do sistema e definir seu perfil de acesso. 1. O ator insere as informações sobre o usuário do sistema a ser incluído: nome, sobrenome, idade, sexo, código de identificação, tipo de identificação, login, a informação de se o usuário está ativo no sistema e os perfis de acesso; 2. O sistema insere o usuário em questão se não existirem usuários no sistema que tenham o mesmo código de identificação e o mesmo tipo de identificação; Nome do caso de uso Objetivo Fluxo principal Pesquisar usuário do sistema Pesquisar os usuários existentes no sistema. 1. O ator insere as informações de pesquisa: nome, sobrenome, idade, sexo, código de identificação, tipo de identificação e o login; 2. O sistema pesquisa os registros de usuários do sistema que satisfaçam os critérios de consulta; 3. O sistema existe o resultado na tela; Nome do caso de uso Objetivo Fluxo principal Atualizar cadastro de usuário do sistema Atualizar os cadastros dos usuários do sistema existentes. 1. O ator pesquisa o usuário de sistema; 2. O ator indica o usuário de sistema a ser atualizado; 3. O ator modifica o nome, sobrenome, sexo, idade, informação de se o usuário está ativo no sistema; 4. O sistema atualiza as informações do usuário interessado em questão se o código de identificação e o tipo de identificação existir no sistema; 65

66 Nome do caso de uso Objetivo Fluxo principal Excluir usuário do sistema Exclui um registro do usuário do sistema existente. Observação: Só será possível realizar este caso de uso caso o registro do usuário do sistema não estiver sendo utilizado, isto é, não possuir dependência com outros registros no sistema. 1. O ator pesquisa o usuário do sistema; 2. O ator indica o usuário de sistema a ser excluído; 3. O sistema exclui o usuário de sistema selecionado se o mesmo não tiver registros de acesso, de acompanhamento, de visita ou de autorização de entrada de usuários casuais gravados até o momento da exclusão; Premissas de funcionamento Para o correto funcionamento do sistema é necessário que: 1. Ocorra o controle físico de acesso nas entradas do hospital para qualquer pessoa que adentrar suas dependências, salvo os funcionários, desde que seja opção da diretoria do hospital de não monitora-los; 2. Nos pontos de controle de acesso físico deve ser entregue um crachá ao usuário do HUB, o qual só poderá sair do recinto ao entregar o respectivo crachá. 3. Cada crachá deve portar uma etiqueta RFID para a detecção da mesma pelo sistema; 4. Cada dependência física deve ter um leitor de RFID em cada entrada, isto é, no início de cada alternativa de acesso à dependência física. 5. Em cada entrada monitorada deve existir um computador conectado a uma intranet para que através desta seja possível a conexão aos serviços do sistema. 6. Que o computador definido para acessar os serviços do sistema tenha instalado pelo menos um explorador de internet. 4.3 Arquitetura do software Esta seção descreve em detalhes a arquitetura do sistema, seus elementos e a integração do mesmo com uma rede RFID. 66

67 O sistema I-Locate é constituído por 5 módulos que se comunicam-se através de interfaces e são apresentados na figura Figura 4.11: Arquitetura lógica do sistema I-Locate, e a integração dos seus 5 módulos. 67

68 Os módulos situados abaixo do módulo ILOCATEWEB são módulos para implementação e funcionamento da rede RFID do hospital. Estes módulos são o EPCIS, o gerador de eventos EPCIS, um middleware e leitores RFID. O módulo ILOCATEWEB trata de uma aplicação WEB que é executado em um servidor HTTP e faz interface com os usuários da aplicação via explorador de internet. A organização e integração destes módulos são uma implementação do framework de arquitetura de rede RFID proposto pela EPCGlobal, como elucidado na seção Segue na figura 4.11 uma breve descrição de cada interface e componente do sistema I-Locate. Interface aérea da etiqueta RFID: meio de comunicação comum entre o leitor e as etiquetas RFID. Não é utilizado atualmente no sistema I-LOCATE pela escolha dos leitores RFID ser opção exclusiva do HUB, isto é, o custo e o preço de diversos leitores presentes no mercado dependerá do que mais se adequará ao interesse da instituição. Leitores RFID: hardwares responsáveis por notificar o middleware acerca da presença de etiquetas no campo de leitura. Estes devem ser instalados em cada meio de acesso às dependências físicas que serão monitoradas pelo sistema. Atualmente o sistema I-Locate utiliza um emulador de leitor físico, permitindo assim o teste do sistema; Interface do leitor: meio de acesso em que o leitor RFID manda as informações de leitura para o middleware. Este meio de comunicação deve ser exclusivamente feito sobre o protocolo TCP/IP para que os leitores possam alcançar as mais diversas dependências físicas do HUB. Módulo do middleware : módulo responsável por centralizar os eventos gerados pelo leitores físicos. Aplica formatação, filtro e lógica aos dados das etiquetas captadas pelos leitores para que o módulo cliente, EPCIS, possa processar estes eventos. É papel também deste módulo desacoplar qualquer meio de acesso do leitor, que podem ser de várias marcas diferentes, das aplicações que desejam capturar os eventos advindos dos mesmos. Interface de filtro e coleção de eventos: Interface utilizada para o envio de relatórios de eventos a serem processados posteriormente pelo gerador de eventos EPCIS. Gerador de eventos EPCIS: Este módulo é responsável por converter os relatórios advindos do middleware para os relatórios que o EPCIS possa compreender. Interface de captura EPCIS: Serviço para o qual o EPCIS aguarda por relatórios do gerador de eventos EPCIS. Os relatórios recebidos por este serviço, serão armazenados pelo EPCIS. Módulo do EPCIS: Módulo responsável por receber os relatórios de eventos de detecção de etiquetas e armazená-los para futuras consultas ou redirecioná-los para qualquer aplicação cliente interessada. 68

69 Interface de consulta EPCIS: Interface responsável por prover meio de consulta de maneira lógica aos dados constates no módulo EPCIS. Módulo I-Locate: Serviço WEB,o qual disponibiliza ao usuários a interface gráfica para realizar os casos de uso indicados na seção 4.2.2; A seguir segue a descrição detalhada de cada módulo citado acima Módulo do leitor RFID Este módulo é representado no sistema por um ou mais leitores RFID. Tais leitores RFID devem integrar-se com o middleware através de uma conexão de rede sobre o protocolo TPC/IP. É necessário que os mesmos sejam previamente configurados para redirecionar os eventos para o host onde se encontra o middleware. É importante frisar que o middleware unifica qualquer tipo de protocolo de alerta de eventos de diferentes marcas e modelos de leitor através de um adaptador. Tal adaptador, é uma interface a ser implementada do ponto de vista da linguagem de programação JAVA 1 e deve ser utilizada a tecnologia EJB 2 para comunicar-se com o adaptador do middleware. Assim, para que se possa integrar qualquer leitor RFID ao sistema, é necessário que seja interposto um driver que traduza o protocolo nativo do leitor para a implementação da interface do adaptador entre o leitor e o middleware. Do ponto de vista do projeto, foi utilizado um software para emular o comportamento de um leitor físico. Este software recebe como entrada o ID do leitor físico, o endereço do servidor onde está sendo executado o middleware e a etiqueta que está disparando o evento. Em seguida, o evento enviado para o adaptador do leitores no middleware através do uso do framework EJB Módulo do middleware Este módulo é necessário para o sistema I-Locate porque filtra os eventos gerados pelos leitores de etiquetas RFID instalados, selecionando os eventos que realmente interessam ao sistema para serem armazenados. Para este propósito foi selecionado o middleware CUHK-RFID Middleware[CUHK, 2008], desenvolvido pela Universidade de Honk Kong. Este software é uma implementação da especificação de serviços de um middleware padrão estabelecido pela EPCGlobal, além de prover interface para aplicações 1 Java é uma linguagem de programação orientada a objeto desenvolvida na década de 90 por uma equipe de programadores chefiada por James Gosling, na empresa Sun Microsystems. Diferentemente das linguagens convencionais, que são compiladas para código nativo, a linguagem Java é compilada para um bytecode que é executado por uma máquina virtual, o que a torna linguagem executada independentemente de plataforma foi cada plataforma possui sua própria máquina virtual. 2 É um dos principais componentes da plataforma J2EE - Java 2 Enterprise Edition. É um componente do tipo servidor que executa no container do servidor de aplicação. Os principais objetivos da tecnologia EJB são fornecer um rápido e simplificado desenvolvimento de aplicações Java baseado em componentes distribuídas, transacionais, seguras e portáveis. 69

70 clientes para redes RFID. Esta interface é estendida para suportar leitura e escrita das memórias da etiquetas. Com ele é possível que os leitores RFID sejam conectados através de uma rede TCP/IP ou através de adaptadores RS-232. Acerca da execução do middleware, este é um software desenvolvido na linguagem Java e disponibiliza seus serviços através do servidor de aplicações Java JBOSS 3 distribuição GA - Zion, customizado pela própria equipe que desenvolveu o middleware. A arquitetura e a interface com os módulos do I-Locate podem ser observadas na figura Figura 4.12: Visão geral da arquitetura do CUHK Middleware. Abaixo a descrição dos elementos da figura 4.12: ALEService - É um stateless session bean4, compreendido como ALEServiceBean. Ela implementa a classe principal da API do middleware e é 3 É um servidor de aplicação de código fonte aberto baseado na plataforma J2EE - Java 2 Enterprise Edition, implementada completamente na linguagem de programação Java. Como é baseada em Java, o JBoss pode ser usado em qualquer Sistema Operacional que suporte Java. 4 É um tipo de componente especificado pelo framework EJB. Estes componentes realizam serviços transientes e atuam como agentes da camada de negócio de uma aplicação web. São executados remotamente e têm o escopo de sessão. 70

71 exposta como um webservice 5, permitindo seus clientes acessá-lo via SOAP 6. TagDataService - É um stateless session bean, compreendido como Tag- DataServiceBean. Ela implementa os serviços estendidos de leitura e escrita de etiquetas do middleware e é exposta via webservice, através do SOAP. ECSpecValidator - É uma classe java utilitária padrão. Ela valida as especificações de relatórios. ECSpecInstance - É um entity bean7, compreendido como ECSpecInstance- Bean. Ela representa uma especificação de relatório (ECSpec) definida no middleware. Ela também modela o ciclo de vida de uma especificação de relatório suportando as transições de estados não-requerido, requerido e ativo. Ela trabalha com o temporizador (Timer) para gerenciar a transição de estados disparados por timeout 8. ReportGenerator - É um stateless session bean. (ECReports) para um dado ciclo de evento. Ele gera os relatórios Notifier - É um message driven bean9. Ela realizar as notificações de relatórios aos clientes escritos, via HTTP(POST) e TCP(XML), e é disparado pelo temporizador (Timer). Timer - É um serviço temporizador embutido. Ele suporta várias operações relacionadas com o timeout. ReaderManager - É um stateless session bean. É um ponto de acesso ao middleware exposto como um serviço EJB. Ele permite o registro de leitores 5 É uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web Services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria linguagem, que é traduzida para uma linguagem universal, o formato XML. 6 Originado do acrônimo inglês Simple Object Access Protocol, é um protocolo para troca de informações estruturadas em uma plataforma descentralizada e distribuída, utilizando tecnologias baseadas em XML. Sua especificação define um framework que provê maneiras para se construir mensagens que podem trafegar através de diversos protocolos e que foi especificado de forma a ser independente de qualquer modelo de programação ou outra implementação específica. 7 É um componente definido na especificação do EJB que representa uma entidade a ser persistida em um banco de dados. 8 Tempo de espera definido como tempo máximo a ser aguardado para execução de um serviço. 9 É um componente definido na especificação do EJB que provê comunicação assíncrona entre cliente e servidor. A mensagem enviada por um cliente chega através do JMS - Java Message Service e é transferida para a respectiva instância do message-driven bean através do container EJB. 71

72 físicos e a agregação das etiquetas lidas pelos mesmos através de adaptadores, utilizando a tecnologia RMI 10 /JRMP 11. As etiquetas lidas são armazenadas em um banco de dados feito na memória para o uso centralizado e compartilhado do middleware. Adaptador do leitor - É um driver, com qual há interface com o driver nativo do leitor físico. Ele recebe os dados das etiquetas lidas e os transmite para o gerenciador de leitores (ReaderManager) via RMI/JRMP. Ele envia ao gerenciador de leitores somente os EPCs distintos, evitando que no mesmo ciclo de leitura haja eventos duplicados removendo os mesmos antes do envio ao middleware. Banco de dados - O middleware pode necessitar lidar com vários leitores ativos ao mesmo tempo. Para gerenciar tal circunstância sem impacto na performace, são utilizadas instâncias de banco de dados em memória e outra em disco. Na instância presente na memória, são armazenadas os eventos de etiquetas lidas pelos leitores e a instância em disco são gravados somente os eventos de leitura que interessam aos cliente especificados através da definição de relatórios a serem enviados aos clientes inscritos no middleware. Serviço de definição de especificação de relatórios - Serviço externo ao middleware com o objetivo de definir como serão os relatórios a serem recebidos pelo serviço de captura de relatórios. Cada especificação de relatório define o conjunto de dados de quais informações o relatório deverá incluir, o intervalo de tempo que será enviado e o endereço HTTP ou TCP de destino. Este serviço é implementado no módulo ILOCATEWEB, figura 4.11, e será descrito no momento oportuno da descrição do módulo em questão. Serviço de captura de relatórios - Serviço externo responsável por receber os relatórios de eventos do middleware, convertê-los para o tipo de relatório do EPCIS e envia-los para o serviço de captura do EPCIS. Este serviço é implementado pelo módulo GERADOR DE EVENTOS EPCIS da figura 4.11; Módulo de gerenciamento do middleware - Módulo responsável por implementar os serviços diversos de gerenciamento de dados que estão no middleware. Este componente é um submódulo embutido no ILOCATEWEB, figura Acrônimo em inglês para Remote Method Invocation. É uma interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java. É uma forma de implementar um sistema distribuído em plataforma Java. A API RMI provê ferramentas para que seja possível ao programador desenvolver uma aplicação sem se preocupar com detalhes de comunicação entre os diversos possíveis elementos hosts de um sistema. A grande vantagem do RMI em relação ao RPC se dá ao fato de ser possível invocar métodos de objetos remotos e transferir objetos complexos entre estes. 11 Acrônimo em inglês para Java Remote Method Protocol, Protocolo de Método Remoto Java) é o protocolo nativo da RMI, mas não é necessariamente o único protocolo que pode ser usado. A RMI pode ser implementada com o IIOP do CORBA. 72

73 4.3.3 Gerador de eventos EPCIS Este módulo é responsável por capturar os relatórios advindos do middleware via HTTP(POST) e enviá-los no formato reconhecido pelo EPCIS. Para isso, deve-se criar um novo relatório, o qual deverá ter sentido de negócio aos seus dados, como por exemplo a localização física dos leitores lógicos informados no relatório do middleware. Após tal criação, o relatório é encaminhado ao host onde está executando o serviço de captura do EPCIS via HTTP(POST). Este módulo é implementado como sub-módulo do ILOCATEWEB e será explanado na seção na descrição da classe IlocateALEReportListener Módulo EPCIS O objetivo do uso deste módulo é de habilitar as aplicações clientes a incorporar dados relacionados com o código EPC ao seu negócio. Ele provê meios de armazenar dados acerca de eventos advindo do middleware e oferece um framework para adicionar dados ao repositório assim como para consultá-los. Para este propósito foi selecionando o software Accada EPCIS Repository[EPCIS, 2008] na versão 0.3.1, licença de uso LGPL (Lesser General Public License) 3.0, que desempenha o papel descrito acima, além de implementar a especificação de EPCIS descrita pelo framework da EPCGlobal. A figura 4.13 ilustra as interfaces do EPCIS. Através da interface de captura de relatórios, o repositório recebe via HTTP(POST) os relatórios convertidos do middleware pelo módulo de GERADOR DE EVENTOS EPCIS e os grava em sua base de dados. Já a interface de consulta permite ao módulo ILOCATEWEB, via SOAP, consultar eventos relacionados com etiquetas que estejam armazenados no EPCIS, além de inscrever um host para recebimento assíncrono de relatórios que o interessa. 73

74 Figura 4.13: Visão geral da arquitetura do repositório EPCIS. 74

75 4.3.5 Módulo ILOCATEWEB Este módulo centraliza os serviços de interface com o usuário implementando os casos de uso idealizados na seção Ele foi desenvolvido com linguagem de programação Java e a utilização do framework JSF A execução deste módulo é realizado em um servidor Tomcat 13 para que os serviços provenientes deste tornem-se acessíveis através de rede intranet. Segue na figura 4.14 os pacotes que compõem a aplicação deste módulo. A descrição do papel de cada um segue abaixo: Pacote br.edu.unb.hub - Pacote principal que contém os demais pacotes constantes neste módulo. Pacote br.edu.unb.hub.apresentacao - Pacote que contém classes que dão suporte a camada de apresentação da aplicação. Cada classe deste pacote representa a lógica das páginas JSP exibidas ao usuário. Quando executadas, as ações do usuário são processadas pela lógica de apresentação da página em questão, formatação e validade dos campos, e após o fluxo de execução é passado para o pacote br.edu.unb.hub.negocio onde são executadas as regras de negócio para a funcionalidade em questão. Pacote br.edu.unb.hub.negocio.dao.util - Pacote responsável por centralizar as classes relacionadas com a lógica de negócio da aplicação. Para realizar este objetivo, este pacote torna-se cliente do pacote br.edu.unb.hub.negocio.dao.hibernate, para acesso ao banco de dados, do pacote infraestrutura, para execução de funcionalidades que requeiram alguma transação no módulo EPCIS, e do pacote br.edu.unb.hub.negocio.dao.util para serviços de cunho utilitário da camada de acesso a dados. Pacote br.edu.unb.hub.negocio.dao.hibernate - Pacote responsável por realizar o acesso à persistência representando a camada de acesso ao banco de dados da aplicação. É utilizado o framework ORM14 Hibernate 15 para o mapeamento das tabelas constantes no banco de dados para objetos. Segue abaixo o modelo de dados empregado para o funcionamento deste módulo. 12 É a API padrão Java para construção de componentes de interface com o usuário nas aplicações WEB, implementando a arquitetura MVC. Ela oferece um conjunto amplo de componentes prontos para serem utilizados nas aplicações WEB. 13 É um servidor WEB Java, mais especificamente, um container de servlets. O Tomcat possui algumas características próprias de um servidor de aplicação, porém não pode ser considerado um servidor de aplicação por não preencher todos os requisitos necessários. Por exemplo, o Tomcat não tem suporte a EJB. Desenvolvido pela Apache Software Foundation, é distribuído como software livre dentro do conceituado projeto Apache Jakarta. 14 É uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registos de cada tabela são representados como instâncias das classes correspondentes. Com esta técnica, o programador não precisa de se preocupar com os comandos em linguagem SQL; irá usar uma interface de programação simples que faz todo o trabalho de persistência. 15 É um framework para o mapeamento objeto-relacional escrito na linguagem Java. 75

76 Pacote br.edu.unb.hub.negocio.dao.util - Pacote de contém classes utilitárias para acesso ao banco de dados. Pacote br.edu.unb.hub.seguranca - Pacote responsável por implementar a proteção de acesso ao módulo ILOCATEWEB. Está proteção é implementada utilizando-se o framework JAAS 16 no servidor TOMCAT que executa o módulo em questão. Ele autentica os usuários da aplicação disponibilizando para toda a aplicação o login do usuário e os perfis de acesso que o mesmo detém. Utiliza o pacote br.edu.unb.hub.negocio.dao.hibernate e br.edu.unb.hub.negocio.dao.util para obter a senha, login e os perfis do usuário do sistema. Pacote br.edu.unb.hub.infraestrutura - Pacote responsável por centralizar todas as funcionalidades de integração com os módulos externos do ILO- CATEWEB. Utiliza o pacote br.edu.unb.hub.negocio.dao.hibernate para acessar a base de dados e o pacote br.edu.unb.hub.util para executar serviços utilitários. Suas principais classes são: ControladorEPCIS - Classe que contém o serviço de início de monitoramento de etiquetas, inscrevendo a classe IlocateEPCISReportListener para receber os relatórios de eventos ocorridos com a respectiva etiqueta, serviço de encerramento de monitoração de etiqueta, serviço de consulta de eventos ocorridos no EPCIS, serviço de atualização de informações da localização de etiquetas na aplicação, e o serviço de consulta de etiquetas monitoradas no contexto da aplicação. IlocateALEInit - Classe que contém o serviço responsável por configurar o módulo do middleware para envio de relatórios de eventos para o host onde se encontra o módulo GERADOR DE EVENTOS EPCIS. O serviço de configuração é automaticamente executado todas as vezes que o servidor Tomcat é inicializado. IlocateALEReportListener - Classe responsável por implementar o papel definido no módulo GERADOR DE EVENTOS EPCIS. Ele recebe de forma síncrona os relatórios de eventos do middleware e os transforma em relatórios que contenham sentido de negócio e em seguida os envia para o EPCIS. IlocateEPCISReportListener - Classe responsável por receber de forma assíncrona os relatórios de eventos advindos do EPCIS. Ela publica as informações contidas nestes relatórios no contexto da aplicação, atualizando as informações de monitoração de etiquetas. 16 Acrônimo em inglês para Java Authentication and Authorization Service. É a implementação da segurança e controle de acessos da máquina virtual java. 76

77 Figura 4.14: Diagrama de classes do módulo ILOCATEWEB. 77

78 Na figura 4.15 é apresentado o modelo de dados utilizado para armazenar os dados referentes ao módulo em questão. 78

79 Figura 4.15: Diagrama de modelo de dados utilizado. 79

80 A figura 4.16 demonstra o diagrama de implantação dos componentes necessários para executar os serviços do I-Locate. Figura 4.16: Diagrama de implantação do módulo ILOCATE. 4.4 Apresentação do software I-Locate Nesta seção é descrito o exemplo de uso do sistema I-Locate. Para acesso ao I- Locate é necessário que o usuário esteja previamente cadastrado no mesmo. Este teste é realizado utilizando-se a autenticação do usuário (Figura 4.17). Realizado o login do usuário com sucesso, o usuário é redirecionado para a página de início do I-Locate como indicado na figura Esta figura descreve a visão das funcionalidades disponíveis para usuários que detenham todos os perfis de acesso, pois o sistema disponibiliza ao usuário somente as opções de serviços em que o usuário está permitido a realizar. Logo, para usuários com diferentes perfis de acesso, o menu principal altera o número de opções disponíveis de acordo com a permissão para execução das mesmas. A tabela 4.1, dispõe as opções disponíveis de acordo com os perfis de acesso existentes no sistema. A lista abaixo descreve as funcionalidades relacionadas com as opções da tabela