ver/abrir - Repositório do Departamento de Ciência da Computação
Transcrição
ver/abrir - Repositório do Departamento de Ciência da Computação
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 a.̄ Dr a.̄ Carla Denise Castanho Brası́lia 2008 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 a.̄ Dr a.̄ Carla Denise Castanho (Orientadora) – CIC/UnB Prof. Dr. Ricardo Pezzuol Jacobi – CIC/UnB Prof a.̄ Dr a.̄ 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, 2008. 110 p. : il. ; 29,5 cm. Monografia (Graduação) – Universidade de Brası́lia, Brası́lia, 2008. 1. 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 70910–900 Brası́lia – DF – Brasil 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 a.̄ Dr a.̄ Carla Denise Castanho (Orientadora) CIC/UnB Prof. Dr. Ricardo Pezzuol Jacobi CIC/UnB Prof a.̄ Dr a.̄ Célia Ghedini Ralha CIC/UnB Prof. Dr. Flávio Leonardo Cavalcanti de Moura Coordenador do Curso de Computação – Licenciatura Brası́lia, 17 de Dezembro de 2008 Agradecimentos Primeiramente agradeço a Deus pela força e saúde que me constituem. À minha orientadora Carla Denise Castanho por me ajudar a consolidar este trabalho de graduação de maneira a reconhecer seu o empenho na minha orientação. Agradeço ainda à minha famı́lia e meus amigos por entenderem a distância e isolamento consequente da realização deste trabalho. Por último, e não menos importante, agradeço a todos pela força e otimismo quando nas horas mais difı́ceis e árduas que se passaram na implementação deste projeto. 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 nele transitam, isto é, o controle do acesso fı́sico às suas dependências. Com mesma importância, certificar-se de que cada um dos usuários e colaboradores transitantes, entre pacientes, médicos, visitantes e funcionários estão nas dependências fı́sicas autorizadas requer monitoração constante da movimentação dos mesmos pela equipe de segurança do hospital. Essa equipe é responsável pelo zelo do patrimônio hospitalar e age proativamente contra qualquer tipo de adversidade que possa colocar em risco a ordem do estabelecimento. Nesse sentido, há dificuldades relacionadas à 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 e colaboradores dentro de um hospital requer a disponibilização de pelo menos um agente para observá-los. 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 fossem monitorados individualmente. O presente trabalho propõe um sistema informatizado cujo objetivo é auxiliar o controle e garantia do acesso de pessoas aos diversos espaços fı́sicos que constituem o Hospital Universitário de Brası́lia (HUB). A solução proposta baseia-se na utilização da tecnologia de identificação por rádio frequência ou RFID, a qual, 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 Abstract The importance of controlling access of people in a hospital environment becomes crucial when taking into account the role of this place, which is to provide services in the area of health care with quality, efficiency and effectiveness. With this in mind, it is important to ensure the purpose of the service through the control of physical access of its facilities. With equal importance, to make sure that each of the users and collaborators, among patients, doctors, visitors, officials and employees, are on physical authorized dependencies requires constant monitoring of the movement by the hospital’s security staff. This team is responsible for the safe keeping of the hospital equipement and proactively acts against any adversity that could endanger the order of the establishment. In this sense, there are intrinsic difficulties to the monitoring activity if it is done with only security agents devoid of specific equipment and technology. A typical activity for monitoring users within a hospital requires at least one guard to observe them. Taking into account that the users within a hospital easily outnumber the guards, an ideal monitoring condition would be unattainable for all users to be monitored individually. This paper proposes a system which goal is help controling and ensuring the access of people to various physical spaces that constitute the University of Brası́lia Hospital (HUB). The proposed solution is based on the use of technology for Radio Frequency Identification, RFID. The RFID technology, still in process of maturation in Brazil, stands out as a method of automated identification using electromagnetic waves to access data stored in a microchip. Keywords: Radio Frequency Identification - RFID, auto-id, tracking system Sumário Lista de Figuras 9 Lista de Tabelas 11 Capı́tulo 1 Introdução 12 Capı́tulo 2 Análise do problema 2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . 2.2 O Hospital Universitário de Brası́lia . . . . . . . . . . 2.2.1 Apresentação, estrutura fı́sica e organizacional 2.2.2 Nı́veis de Acesso e Problemas de Segurança . 2.3 Objetivos e Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14 14 14 18 20 Capı́tulo 3 Fundamentação Teórica 3.1 Sistemas de informação . . . . . . . . . . . 3.1.1 Tipos de sistemas de informação . . 3.1.2 Tecnologia da informação . . . . . 3.2 A tecnologia RFID . . . . . . . . . . . . . 3.2.1 A História da RFID . . . . . . . . 3.2.2 A Arquitetura da tecnologia RFID 3.2.3 Padrão EPCGlobal . . . . . . . . . 3.2.4 Redes RFID Distribuı́das . . . . . . 3.2.5 Aplicações da tecnologia RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 22 25 26 26 27 34 37 45 . . . . . . . . . . . . . . . . . . . . . . . . . . . Capı́tulo 4 Sistema de controle e monitoração de 4.1 Processos de negócio existentes na instituição . 4.2 Necessidades do sistema . . . . . . . . . . . . . 4.2.1 Introdução . . . . . . . . . . . . . . . . . 4.2.2 Requisitos funcionais . . . . . . . . . . . 4.2.3 Premissas de funcionamento . . . . . . . 4.3 Arquitetura do software . . . . . . . . . . . . . 4.3.1 Módulo do leitor RFID . . . . . . . . . . 4.3.2 Módulo do middleware . . . . . . . . . 4.3.3 Gerador de eventos EPCIS . . . . . . . . 4.3.4 Módulo EPCIS . . . . . . . . . . . . . . 4.3.5 Módulo ILOCATEWEB . . . . . . . . . 4.4 Requisitos de infra-estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acesso: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-Locate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 49 53 53 54 57 58 60 60 64 64 65 71 4.5 Apresentação do software I-Locate . . 4.5.1 Gerenciar acesso a dependências 4.5.2 Gerenciar usuários . . . . . . . 4.5.3 Gerenciar etiquetas . . . . . . . 4.5.4 Administrar usuários do sistema 4.5.5 Administrar sistema . . . . . . 4.5.6 Considerações finais . . . . . . . . . . . fı́sicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 74 76 78 78 78 88 Capı́tulo 5 Conclusão 5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 89 Capı́tulo 6 Anexo 91 6.1 Detalhamento da especificação dos casos de uso do sistema I-Locate 91 Referências 109 8 Lista de Figuras 2.1 2.2 2.3 Visão áerea do HUB. . . . . . . . . . . . . . . . . . . . . . . . . . Visão frontal do HUB. . . . . . . . . . . . . . . . . . . . . . . . . Estrutura organizacional do HUB. . . . . . . . . . . . . . . . . . . 15 16 17 3.1 3.2 3.3 3.4 3.5 Atividades de um SI, retirado de [LAUDON, 2007] . . . . . . . . Tipos de SIs, retirado de [LAUDON, 2007] . . . . . . . . . . . . . Etiquetas RFID diversas, retirado de [Himanshu Bhatt, 2006] . . Etiquetas RFID afixadas em plástico, retirado de [SANTINI, 2006] Etiqueta em formato de cartão de crédito (Smart Card), retirado de [SANTINI, 2006] . . . . . . . . . . . . . . . . . . . . . . . . . Etiqueta RFID embutido no relógio, retirado de [SANTINI, 2006] Etiqueta RFID afixado em um bracelete, retirado de [SANTINI, 2006] Exemplo de leitor RFID, retirado de [Himanshu Bhatt, 2005] . . . Organização lógica de um leitor, adaptado de [Himanshu Bhatt, 2006] Arquitetura de um middleware para sistemas RFID, adaptado de [Himanshu Bhatt, 2006] . . . . . . . . . . . . . . . . . . . . . . . Sistema RFID centrado na aplicação . . . . . . . . . . . . . . . . Sistema RFID centrado na rede. . . . . . . . . . . . . . . . . . . . Arquitetura amontoada. . . . . . . . . . . . . . . . . . . . . . . . Arquitetura dedicada. . . . . . . . . . . . . . . . . . . . . . . . . Etiqueta RFID afixada em cadarço de tênis [Finkenzeller, 2003]. 21 22 30 30 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 Diagrama de atividade do cadastro de entrada do usuário do tipo visitante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Diagrama de atividade do cadastro de entrada do usuário do tipo acompanhante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Diagrama de atividade do cadastro de entrada do usuário casual. . 4.4 Diagrama de fluxo de dados . . . . . . . . . . . . . . . . . . . . . 4.5 Diagrama do caso de uso do ator “usuário genérico”. . . . . . . . 4.6 Diagrama do caso de uso do ator “gerenciador de etiquetas”. . . . 4.7 Diagrama do caso de uso do ator “funcionário da segurança”. . . . 4.8 Diagrama do caso de uso do ator “supervisor da segurança”. . . . 4.9 Diagrama do caso de uso do ator “suporte técnico do sistema”. . . 4.10 Diagrama do caso de uso do ator “gestor do sistema”. . . . . . . . 4.11 Arquitetura lógica do sistema I-Locate, e a integração dos seus 5 módulos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Visão geral da arquitetura do CUHK Middleware. . . . . . . . . . 31 31 31 33 33 34 38 38 40 41 46 4.1 51 51 51 52 54 55 55 56 56 57 58 61 4.13 Visão geral da arquitetura do repositório EPCIS, adaptado de [CUHK, 2008b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14 Diagrama de classes do módulo ILOCATEWEB. . . . . . . . . . . 4.15 Diagrama de modelo de dados do I-Locate. . . . . . . . . . . . . . 4.16 Diagrama de implantação do módulo ILOCATE. . . . . . . . . . . 4.17 Tela de login do sistema. . . . . . . . . . . . . . . . . . . . . . . . 4.18 Página inicial do I-Locate. . . . . . . . . . . . . . . . . . . . . . . 4.19 Formulário de inserção de registro de acesso às dependências fı́sicas. 4.20 Opções de monitoração de etiquetas RFID. . . . . . . . . . . . . . 4.21 Monitoração de usuários no espaço nas dependências fı́sicas. . . . 4.22 Formulário para localização de etiquetas. . . . . . . . . . . . . . . 4.23 Resultado para a busca de etiquetas. . . . . . . . . . . . . . . . . 4.24 Formulário para geração de relatórios de ocorrências de monitoração de etiquetas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.25 Gerenciamento de usuários cadastrados no sistema. . . . . . . . . 4.26 Gerenciamento de etiquetas cadastrados no sistema. . . . . . . . . 4.27 Administração dos usuários do sistema. . . . . . . . . . . . . . . . 4.28 Administração do sistema. . . . . . . . . . . . . . . . . . . . . . . 4.29 Opção Conexões do menu Administrar sistema. . . . . . . . . . . 4.30 Hosts inscritos para recepção de eventos do middleware. . . . . . . 4.31 Especificações de relatórios de eventos. . . . . . . . . . . . . . . . 4.32 Leitores lógicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.33 Leitores fı́sicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 68 70 72 73 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 Lista de Tabelas 3.1 3.2 3.6 SI do ponto de vista funcional, retirado de [LAUDON, 2007] . . . Classificação de raios de frequências para dispositivos RFID. Tópico 3.4.1 em [Himanshu Bhatt, 2006]. . . . . . . . . . . . . . . . . . . Raio máximo de leitura para etiquetas passivas de acordo com a freqüência. Tópico 3.4.1 em [Himanshu Bhatt, 2006]. . . . . . . . Classes de etiquetas do padrão EPCGlobal. Tópico 10.4.1.1.1 em [Himanshu Bhatt, 2005]. . . . . . . . . . . . . . . . . . . . . . . . Principais caracterı́sticas das arquiteturas de rede RFID, retirado de [Yi Zhi Zhao, 2007]. . . . . . . . . . . . . . . . . . . . . . . . . Código eletrônico de produtos: EPC . . . . . . . . . . . . . . . . 42 44 4.1 Acessibilidade das opões do menu principal do I-Locate. . . . . . . 73 3.3 3.4 3.5 24 32 32 35 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 nu, 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 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 às 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 12 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 HUB. 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. 13 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 HUB atualmente carece de um controle eficaz deste processo, conforme levantamento e estudo apresentado em [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 2.2.1 O Hospital Universitário de Brası́lia Apresentação, estrutura fı́sica e organizacional O HUB [HUB, 2007] teve seu funcionamento autorizado pelo Decreto n.o 70.178 de 21 de fevereiro de 1972. 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 14 1990, foi cedido à Universidade de Brası́lia (UnB) em ato assinado pelo Presidente Fernando Collor e passou a se chamar HUB. O HUB conta atualmente com 289 leitos, 121 salas de Ambulatório e 41.170 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 16.000 consultas, com cerca de 900 internações. O Pronto Socorro realiza, aproximadamente, 3.500 consultas. No total, o HUB faz 36.000 atendimentos a cada mês. São feitos cerca de 60.000 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. Figura 2.1: Visão aérea do HUB. 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 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 15 Figura 2.2: Visão frontal do HUB. 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 que 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 efetivada 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. 16 Figura 2.3: Estrutura organizacional do HUB. 17 Atualmente não existe controle de acesso neste complexo sendo a entrada para funcionários, visitantes ou pacientes sempre autorizada. 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 (1o andar Anexo II), onde o acesso é livre, e na Internação (2o 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 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 o trâmite no hospital é restringido pelo crachá ou pelos uniformes relativos as funções do hospital (Ex.: jaleco). 2.2.2 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 HUB. 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 18 que outra pessoa visite o paciente. Anexo I • Térreo e 1o 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. • 2o ,3o e 4o 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, ou seja, uma pessoa pode acompanhá-los independente do horário. Anexo II • Térreo e 1o andar: o acesso é livre. O problema recorrente é que a Odontologia (1o andar) sofre furtos já que seus equipamentos são pequenos e de fácil ocultamento. • 2o 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 1o andar e no térreo o acesso é livre, muitos usuários informam seu destino final como a odontologia, mas sobem para o 2o andar, onde encontram-se os pacientes internados. Somente em alguns horários é designado um agente de segurança para vigiar o acesso ao 2o 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 19 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 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 existentes com a integração da tecnologia RFID. Além da arquitetura do software serão apresentados a interface final com usuário e a documentação dos casos de usos pertinentes às funcionalidades oferecidas pelo sistema. 20 Capı́tulo 3 Fundamentação teórica 3.1 Sistemas de informação Um sistema de informação (SI) pode ser definido tecnicamente como um conjunto de componentes inter-relacionados que coletam, processam, armazenam e distribuem informações destinadas à coordenação e ao controle dos processos de negócio1 de uma organização2 [LAUDON, 2007]. Três atividades em um SI produzem as informações de que as organizações necessitam para controlar operações, analisar problemas e criar novos produtos e serviços. Essas atividades são a entrada, o processamento e a saı́da. A entrada envolve a captação ou coleta dos dados, o processamento envolve processos de transformação que converte insumo a entrada em produto e a saı́da envolve a transferência da informação processada para o usuário final. A Figura 3.1 demonstra as atividades do SI. Figura 3.1: Atividades de um SI, retirado de [LAUDON, 2007] Embora os SIs utilizem a tecnologia de computadores para processar dados 1 São atividades previamente estabelecidas que têm como objectivo determinar a forma como o trabalho é realizado numa organização. Constituem um conjunto de ações, relacionadas entre si de forma lógica e coerente a fim de promover um resultado favorável à organização, tanto a nı́vel interno como externo [LAUDON, 2007]. 2 É uma combinação de esforços individuais que tem por finalidade realizar propósitos coletivos. Por meio de uma organização torna-se possı́vel perseguir e alcançar objetivos que seriam inatingı́veis para uma pessoa. Uma grande empresa ou uma pequena oficina, um laboratório ou o corpo de bombeiros, um hospital ou uma escola são todos exemplos de organizações [Maximiano, 1995]. 21 brutos e transformá-los em informações inteligı́veis, existe uma diferença entre um computador e um software, de um lado, e um SI, de outro. Os computadores são ferramentas modernas que permitem aos SIs executar suas finalidades, enquanto que o SI pode não utilizar-se necessariamente de computadores para a execução de seus processos [LAUDON, 2007]. 3.1.1 Tipos de Sistemas de Informação Por causa de diferentes interesses, especialidades, e nı́veis na organização, existem diferentes tipos de sistemas. Nenhum sistema pode prover todas as informações que uma organização necessita [LAUDON, 2007]. A Figura 3.2 ilustra a maneira de classificar os tipos de sistemas encontrados em uma organização. Ela demonstra a organização dividida em nı́veis estratégicos, gerenciais, de conhecimento e operacionais, além de serem subdivididas do ponto de vista funcional nas áreas de vendas e marketing, fabricação, finanças, contabilidade e recursos humanos. Figura 3.2: Tipos de SIs, retirado de [LAUDON, 2007] A seguir têm-se a descrição de cada classificação dos nı́veis de um SI. • Sistemas de nı́vel operacional: sistemas que suportam os gestores operacionais na definição das atividades elementares e transacionais das organizações, tais como vendas, recepção de encomendas, faturação, aprovisionamento, decisões de crédito e fluxo de materiais. O principal objetivo destes sistemas é dar resposta a questões de rotina e traçar o fluxo de transações das organizações. 22 • Sistemas de nı́vel do conhecimento: sistemas que suportam os “trabalhadores do conhecimento”nas organizações. Estes sistemas têm como propósito ajudarem as organizações a integrarem conhecimento novo no negócio e a controlarem o fluxo de documentos (papeis de trabalho). Temos como exemplos os sistemas de processamento de texto e os sistemas de desenho assistido por computador. • Sistemas de nı́vel táctico/gestão: sistemas construı́dos para servirem os gestores intermédios nas atividades de monitoragem, controle, tomada de decisão e administrativas. Geralmente disponibilizam relatórios periódicos em vez de informações sobre as operações do momento. Alguns destes sistemas suportam tomadas de decisão não rotineiras e tendem a focarse sobre tomadas de decisão não estruturadas para as quais os requisitos de informação não são claros. Muitas vezes estes sistemas dão resposta a questões do tipo “e se”que permitem estudar vários cenários. As respostas a estas questões requerem frequentemente dados novos vindos do exterior das organizações, bem como dados de dentro da organização, que não podem ser obtidos a partir dos sistemas de nı́vel operacional. • Sistemas de nı́vel estratégico: sistemas que ajudam os gestores principais a encontrar e a definir estratégias de longa duração. Estes têm como principal objetivo encontrar alterações no ambiente externo das organizações. Estes sistemas devem ser capazes de dar resposta a questões do tipo: que produtos podemos/devemos produzir durante os próximos anos? etc. Os sistemas estratégicos geralmente diferem dos não estratégicos em muitos atributos: benefı́cios difı́ceis de avaliar; podem levar a poderosas mudanças internas; podem transformar drasticamente os padrões de trabalho; são usualmente caros, em termos de custos de oportunidades e riscos; têm por objetivo proporcionar vantagens competitivas sustentadas; e pouca experiência onde se possam basear. As principais caracterı́sticas encontradas do ponto de vista funcional dos SIs podem ser encontradas na Tabela 3.1. 23 Sistema Vendas e marketing Função Gestão de vendas, pesquisa de mercado, promoção, definição de preços, novos produtos. Fabricação e produção Estabelecimento de metas de produção, compras, expedição, recepção, engenharia, operações. Controle de estoques Orçamento, livro-caixa, cobrança, contabilidade de custos. Recursos humanos Registros de pessoal, benefı́cios, remuneração, relações trabalhistas, treinamento. Aplicação Sistemas de acompanhamento de pedidos, sistema de pesquisa de mercado, sistema de estabelecimento de preços. Sistemas de planejamento de recursos, Sistemas de controle de pedidos de compra, sistemas de engenharia, sistemas de controle de qualidade. Livro-caixa, contas a receber, contas a pagar, orçamento, sistemas de gestão financeira. Folha de pagamentos, registros de funcionários, sistemas de benefı́cios, sistemas de planos de carreira, sistemas de treinamento de pessoal. Tabela 3.1: SI do ponto de vista funcional, retirado de [LAUDON, 2007] 24 3.1.2 Tecnologia da informação Entende-se como a tecnologia da informação (TI), o hardware e o software usado para adquirir, transmitir, processar e disseminar informação, bem como sistemas de gerenciamento de banco de dados e tecnologias de comunicação de dados [GORDON, 2006]. O hardware de computador refere-se ao equipamento utilizado no processamento eletrônico das informações. Hoje em dia, computadores de mesa e computadores portáteis podem exceder em desempenho os enormes computadores de um milhão de dólares de dez anos atrás. • O hardware de entrada captura dados no seu formato bruto, primário, e informações de uso interativo. • O hardware de processamento converte ou transforma dados. • O hardware de armazenamento inclui mı́dias fixas e removı́veis que permitem acesso rápido às informações. • O hardware de saı́da fornece cópias dos dados em papel, microfilmes, e telas de vı́deo. O software de computador fornece as instruções, na forma de código de computador, e sua documentação correspondente, para processar eletronicamente os dados. • O software de sistemas dirige o funcionamento do hardware. • O software de aplicação atua na aquisição, processamento, armazenamento, recuperação e comunicação da informação. • Ferramentas de desenvolvimento de software facilitam a construção e modificação do software para melhor responder às necessidades de informação de uma organização. Os sistemas de gerenciamento de banco de dados oferecem veı́culos para armazenar e dar suporte ao processamento de grandes quantidades de informações de negócios, tais como dados sobre os empregados, produtos, clientes e fornecedores. Esta tecnologia permite aos gestores facilmente acessar, classificar e analisar bancos de dados de informação das mais variadas formas. As tecnologias de comunicação de dados, especificamente as redes das empresas e a Internet, uma rede de redes de alcance mundial, aperfeiçoaram dramaticamente a comunicação das informações entre pequenas e grandes distâncias, tornando-se um fator importante na TI [GORDON, 2006]. Em se tratando do avanço da TI, esta torna-se uma tecnologia para grande amparo de um SI, pois possibilita o eficiente monitoramento e manipulação de dados. É possı́vel não só reduzir o gasto de papel, canetas, tinta de impressão, mas além da economia financeira, a possibilidade da economia de tempo e esforço relacionados às atividades de manipulação de dados de um SI. Como exemplo, pode-se citar a implementação dos processos de identificação de pessoas 25 no para o controle de acesso no hospital através do registro manuscrito em atas pelos agentes de segurança. O mesmo controle pode ser feito utilizando-se os sistemas computacionais, o que garantiria a consistência dos dados de entrada e saı́da deste processo, além de facilitar a auditoria do mesmo considerando-se o armazenamento dos dados do agente que autorizou a entrada da pessoa no HUB, da pessoa que entrou e as dependências fı́sicas que a mesma está autorizado a transitar. 3.2 A Tecnologia RFID A tecnologia RFID 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 na 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 computacional 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). 3.2.1 A História da RFID A história da tecnologia RFID pode ser descrita segundo as indicações em [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 frequência, boa parte é devida ao 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, pois 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 se o avião 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 26 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 13.56 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 dispositivos 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. 3.2.2 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, como indicado no tópico 2.3.1 em [Himanshu Bhatt, 2006]. Esta ação, no contexto do SI que a utiliza, desencadeia 27 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. 3.2.2.1 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, chips, ou rótulos. De maneira geral, uma etiqueta de RFID pode conter os seguintes itens: • • • • • Circuito de codificação e decodificação; Memória; Antena; Fonte de alimentação; Controle de comunicação; Ainda assim elas se dividem em três categorias: ativas, passivas e semipassivas, 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. Etiquetas Ativas Em contraposição à ideia de recurso de alimentação, as etiquetas RFID ativas têm seus próprios meios de alimentação, isto é, não necessitam de serem alimentadas por um campo próximo gerado pela antena do leitor, podendo por consequência transmitir e receber dados a maiores distâncias do que as etiquetas 28 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 ou 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.3 a 3.7 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 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, frequências que foram 29 Figura 3.3: Etiquetas RFID diversas, retirado de [Himanshu Bhatt, 2006] Figura 3.4: Etiquetas RFID afixadas em plástico, retirado de [SANTINI, 2006] 30 Figura 3.5: Etiqueta em formato de cartão de crédito (Smart Card ), retirado de [SANTINI, 2006] Figura 3.6: Etiqueta RFID embutido no relógio, retirado de [SANTINI, 2006] Figura 3.7: Etiqueta RFID afixado em um bracelete, retirado de [SANTINI, 2006] 31 reservadas especificamente para aplicações industriais, cientı́ficas ou médicas como como frequência de operação das etiquetas RFID. Tais frequências são conhecidas como faixa de freqüência ISM (Industrial-Scientific-Medical). As tabelas 3.2 e 3.3, sumarizam as faixas de frequências, bem como suas caracterı́sticas e aplicações tı́picas. Nome LF HF Raio de frequência 30300kHz 330M Hz UHF 300M Hz − 3GHz Microondas > 3GHz Frequência ISM < 135kHz 6.78M Hz, 13.56M Hz, 27.125M Hz, 40.680M Hz 433.920M Hz, 869M Hz, 915M Hz 2.45GHz, 5.8GHz, 24.125GHz Tabela 3.2: Classificação de raios de frequências para dispositivos RFID. Tópico 3.4.1 em [Himanshu Bhatt, 2006]. O raio da leitura em função das frequências é mostrado na Tabela 3.2. Nome LF Raio de leitura 50 centı́metros HF 3 metros UHF 9 metros Microondas > 10 metros Aplicação Identificação de animais e leitura a curta distância Controle de acesso a dependências fı́sicas. Identificação de caixas e paletes. Identificação de veı́culos. Tabela 3.3: Raio máximo de leitura para etiquetas passivas de acordo com a freqüência. Tópico 3.4.1 em [Himanshu Bhatt, 2006]. 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, como indicado no tópico 3.5 em [Himanshu Bhatt, 2006]. 3.2.2.2 Leitor O segundo componente básico de um sistema RFID é chamado de leitor ou interrogador. 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 32 Figura 3.8: Exemplo de leitor RFID, retirado de [Himanshu Bhatt, 2005] 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 transmitem 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.9) . Figura 3.9: Organização lógica de um leitor, adaptado de [Himanshu Bhatt, 2006] 3.2.2.3 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. A Figura 3.10 demonstra a visão lógica da 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; 33 Figura 3.10: Arquitetura de um middleware para sistemas RFID, adaptado de [Himanshu Bhatt, 2006] • 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. 3.2.3 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. • 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. • Leitor de Radiofrequê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 34 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: SI 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 EPCGlobal, com exceção do leitor e middleware, esclarecidos nas seções 3.2.2.2 e 3.2.2.3 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, os quais são definidos por entidades especı́ficas, que possuem as classes de objetos fı́sicos envolvidos. A Tabela 3.4 mostra as diferentes classificações das etiquetas reconhecidas pela ECPGlobal: Classe Classe Classe Classe Classe 0 1 2 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 de maneira ativa com leitores e outras etiquetas ativas. Todas funcionalidades da classe 4 somadas a capacidade de comunicação com etiquetas passivas. Conceitualmente leitores. Tabela 3.4: Classes de etiquetas do padrão EPCGlobal. Tópico 10.4.1.1.1 em [Himanshu Bhatt, 2005]. Código eletrônico de produtos - EPC 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: 35 • • • • 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 exemplos de informações 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 da etiqueta). Serviço de nomeação de objetos 36 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: 0100000000000000000001000000000000011000000000000000000110010000 2. O leitor então transmite a mensagem, através do middleware, para um servidor destinado a converter a sequência de bits em URI (identificador uniforme de recursos); 3. Depois de convertida a sequência de bits em um URI, este servidor envia um a requisição ao servidor ONS local a seguinte resolução: urn:epc:1.2.24.400; 4. O servidor ONS converte a URI em identificador de domı́nio e então passa ao DNS a requisição: 24.2.1.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: http://pml.unb.br/pml-wsdl.xml; 7. O servidor local contata o servidor PML correto obtido através da URL para o EPC em questão; 3.2.4 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.11). 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 3.12. 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. 3.2.4.1 Elementos da concepção de redes RFID distribuı́das Redes Dedicadas e Amontoadas 37 Figura 3.11: Sistema RFID centrado na aplicação Figura 3.12: Sistema RFID centrado na rede. 38 Todos os objetos exceto para a aplicação RFID A, B e middleware na porção superior da Figura 3.12 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 expansibilidade 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.13, 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.14, 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. 39 Figura 3.13: Arquitetura amontoada. 40 Figura 3.14: Arquitetura dedicada. 41 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. Arquitetura Facilidade Sub-redes VLAN Tratamento de segurança na sobrecarga de tráfego Escalabilidade Amontoada Disponibilidade de portas nos switches secundários e principal. É 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. Conecta as portas disponı́veis para a mesma rede local virtual de RFID (precisa de switches secundários para suportar a VLAN). Vulnerável por causa de restrições da segmentação e a posição do middleware na rede. Limitado Dedicada Disponibilidade de portas no switch e principal somente. É 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 pelo middleware no interior da rede RFID, ou por roteadores do tipo firewall dedicados. Flexı́vel Tabela 3.5: Principais caracterı́sticas das arquiteturas de rede RFID, retirado de [Yi Zhi Zhao, 2007]. 42 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 de 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.6 mostra uma amostra de um EPC de 96 bits. Assumindo-se que o EPC é a única coisa armazenada no chip, e por consequência, é o único dado que é passada da etiqueta para o leitor, o leitor tem 43 01 8 bits Cabeçalho Determina a estrutura de dados da etiqueta. OOOOA89 28 bits Gerente do domı́nio Identifica a entidade responsável por manter os números subsequentes 00016F 24 bits Classe do objeto 0001S9DC0 36 bits Número serial Representa a classe do objeto Identificação única do objeto. Tabela 3.6: 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. P 1) Etiqueta para o leitor: BW t = N i=1 (St ∗ XAi) Onde S t é 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 P 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 44 nesta camada deve ser quantificado de acordo com a especificação da aplicação. 3.2.5 Aplicações da Tecnologia RFID Por consequê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 radiofrequê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]. 3.2.5.1 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 microchips RFID contidos no cartão de ingresso emitem um sinal de rádio que é captado por leitores on-line nas entradas dos [theregister, 2008b]. Na área médica, a identificação humana através de microchips 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 45 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, além da bilhetagem, etiquetas são utilizadas também em corridas, aplicadas no cadarço dos corredores, Figura 3.15 para saber com exatidão o tempo percorrido como citado em [Finkenzeller, 2003], página 179. Este tipo de aplicação torna-se útil principalmente em provas onde a quantidade de corredores é muito grande. Figura 3.15: Etiqueta RFID afixada em cadarço de tênis [Finkenzeller, 2003]. 3.2.5.2 Computação Ubı́qua 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 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 46 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 frequentemente um foco de atenção, e, por vezes, um obstáculo a esse trabalho [Weiser, 1993]. Baseado nessas questões, em 1988 Mark Weiser e vários de seus companheiros do PARC elaboraram as primeiras ideias 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 and Brown, 1997] 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 canetas, roupas, relógios, portas e cadeiras. A miniaturização do computador e a diminuição dos custos de seus compo47 nentes 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 ideia 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 [Weiser, 1993]. Nesse artigo, os autores descrevem a utilização de sensores de localização 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]. 48 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: 49 • 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 nas figuras 4.1, 4.2 e 4.3. 2. 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 50 Figura 4.1: Diagrama de atividade do cadastro de entrada do usuário do tipo visitante. 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. 51 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 52 4.2 4.2.1 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 middleware 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; 53 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”. 54 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”. 55 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”. 56 Figura 4.10: Diagrama do caso de uso do ator “gestor do sistema”. O funcionamento de cada caso de uso representado nos diagramas 4.5 a 4.10 são detalhados em anexo na Seção 6.1. 4.2.3 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. 57 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. O sistema I-Locate é constituı́do por 5 módulos que se comunicam-se através de interfaces e são apresentados na Figura 4.11. Figura 4.11: Arquitetura lógica do sistema I-Locate, e a integração dos seus 5 módulos. 58 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 3.2.3. 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. 59 • 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. 4.3.1 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 JAVA1 e deve ser utilizada a tecnologia EJB2 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. 4.3.2 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, 2008a], 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 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. 60 aplicações 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 JBOSS3 distribuição 4.0.4.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 4.12. 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 bean 4 , compreendido como ALEServiceBean. Ela implementa a classe principal da API do middleware e é exposta como um webservice 5 , permitindo seus clientes acessá-lo via SOAP 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. 5 É uma solução utilizada na integração de sistemas e na comunicação entre aplicações difer- 61 6 . • TagDataService - É um stateless session bean, compreendido como TagDataServiceBean. 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 bean 7 , compreendido como ECSpecInstanceBean. 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 bean 9 . 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 fı́sicos e a agregação das etiquetas lidas pelos mesmos através de adapentes. 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. 62 tadores, utilizando a tecnologia RMI10 /JRMP11 . 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 4.11. 10 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. 63 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, devese 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 4.3.5 na descrição da classe IlocateALEReportListener. 4.3.4 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. 64 Figura 4.13: Visão geral da arquitetura do repositório EPCIS, adaptado de [CUHK, 2008b] 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 4.2.2. Ele foi desenvolvido com linguagem de programação Java e a utilização do framework JSF12 1.2. A execução deste módulo é realizado em um servidor Tomcat13 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 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. 65 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 Hibernate15 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. • 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 JAAS16 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 ILOCATEWEB. 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 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. 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. 66 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. 67 Figura 4.14: Diagrama de classes do módulo ILOCATEWEB. 68 Na Figura 4.15 é apresentado o modelo de dados utilizado para armazenar os dados referentes ao módulo em questão. 69 Figura 4.15: Diagrama de modelo de dados do I-Locate. 70 A Figura 4.16 demonstra o diagrama de implantação dos componentes necessários para executar os serviços do I-Locate. 4.4 Requisitos de infra-estrutura A infra-estrutura da rede do HUB em que trafegam informações organizacionais deve ser separada da rede RFID para que não haja mistura da possı́vel carga de dados gerada pela leitura de etiquetas RFID, ou seja, deve-se montar uma rede dedicada para os nodos de rede que vão desde os leitores até o middleware. Esta estrutura de rede é identificada como rede RFID dedicada e está esplanada no item 3.2.4.1. 4.5 Apresentação do software I-Locate Nesta seção é descrito o exemplo de uso do sistema I-Locate. Para acesso ao ILocate é 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 4.18. 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 4.1. As opções do menu principal são as seguintes: • Opção 1: Gerenciar acesso a dependências fı́sicas; • Opção 2: Gerenciar usuários; • Opção 3: Gerenciar etiquetas; • Opção 4: Administrar usuários do sistema; • Opção 5: Administrar sistema; Observa-se que os usuários com o perfil ILOC300 não possuem acesso a qualquer opção do sistema por se tratar de um perfil de acesso dependente do perfil ILOC200 para funcionar. Isto ocorre por que o usuários com perfil ILOC300 são uma extensão do perfil de acesso ILOC200. A seguir são descritos os funcionamentos do menu. 71 Figura 4.16: Diagrama de implantação do módulo ILOCATE. 72 Figura 4.17: Tela de login do sistema. Figura 4.18: Página inicial do I-Locate. Perfil/Menu ILOC100 ILOC200 ILOC300 ILOC400 ILOC500 Opção 1 Opção 2 X X Opção 3 X Opção 4 Opção 5 X X Tabela 4.1: Acessibilidade das opões do menu principal do I-Locate. 73 4.5.1 Gerenciar acesso a dependências fı́sicas Esta opção permite ao usuário do sistema gerir o registro de acesso às dependências fı́sicas bem como monitorar a localização dos usuários que adentraram no HUB através com o crachá do portador. A Figura 4.19 demonstra o formulário em que é possı́vel inserir os dados do registro de acesso de um indivı́duo nas dependências do HUB. Este formulário muda dinamicamente conforme o tipo de indivı́duo quanto a finalidade (funcionário, paciente, visitante, acompanhante). Preenchido os dados necessários, deve-se salvar o registro de acesso apertando o botão “Salvar registro de acesso”. Figura 4.19: Formulário de inserção de registro de acesso às dependências fı́sicas. Nas ocasiões em que o usuário estiver saindo do HUB, é necessário buscar o registro de acesso em aberto preenchendo-se o campo de código de etiqueta e apertando-se em “Buscar registro de acesso existente”. Após, aperta-se no botão “Encerrar registro de acesso”. A Figura 4.20 mostra a aba de monitoração de etiquetas. Ela disponibiliza as seguintes opções: • Monitorar espaço fı́sico - Opção que permite monitorar todo o espaço fı́sico. Os portadores da etiquetas identificados quando na entrada do HUB são representados nas dependências fı́sicas através de ı́cones na planta do hospital conforme a Figura 4.21. Ao passar o ponteiro do mouse sobre quaisquer dos 74 Figura 4.20: Opções de monitoração de etiquetas RFID. 75 ı́cones, é possı́vel obter a breve descrição do registro de aceso do portador da etiqueta. Etiquetas cujos portadores estão em estado irregular, isto é, local indevido ou horário não permitido aparecem com um indicador vermelho para facilitar ao usuário da aplicação a visualização da irregularidade. • Localizar etiquetas - Esta opção permite ao usuário localizar a etiqueta pelo seu código de sistema ou identificação do usuário. A Figura 4.22 demonstra o formulário onde serão inseridos os dados requeridos para localização. Caso seja localizada a etiqueta, é mostrado o ı́cone representando o portador da etiqueta na respectiva localização fı́sica como mostra a Figura 4.23. • Relatório de monitoração de etiquetas - Esta opção está disponı́vel somente para usuários que contem o perfil de acesso ILOC300. Ela permite gerar relatórios de monitoração de etiquetas de acordo com os critérios de geração. A Figura 4.24. mostra um exemplo de relatório gerado. Figura 4.21: Monitoração de usuários no espaço nas dependências fı́sicas. 4.5.2 Gerenciar usuários Esta opção permite gerenciar os usuários cadastrados no sistema. Ela oferece as opções de pesquisa, criação, atualização e exclusão de registros de usuários utilizados pelo sistema para registro de acesso. A Figura 4.25 mostra o formulário com os campos providos para tais finalidades. 76 Figura 4.22: Formulário para localização de etiquetas. 77 Figura 4.23: Resultado para a busca de etiquetas. 4.5.3 Gerenciar etiquetas Esta opção permite gerenciar as etiquetas RFID cadastrados no sistema. Ela oferece as opções de pesquisa, criação, atualização e exclusão de registros de etiquetas. A Figura 4.26 mostra o formulário com os campos providos para tais finalidades. 4.5.4 Administrar usuários do sistema Esta opção permite gerenciar os usuários do sistema bem como seus respectivos perfis de acesso no sistema. Ela oferece as opções de pesquisa, criação, atualização e exclusão de registros de usuário do sistema. A Figura 4.27 mostra o formulário com os campos providos para tais finalidades. 4.5.5 Administrar sistema Esta opção tem a finalidade de prover funcionalidades utilitárias acerca dos módulos externos ao ILOCATEWEB. A Figura 4.28 mostra as funcionalidades disponı́veis nesta opção. • Informações sobre etiquetas detectadas no sistema - Esta opção exibe os valores atualizados das etiquetas que foram detectadas pelo sistema, Figura 78 Figura 4.24: Formulário para geração de relatórios de ocorrências de monitoração de etiquetas. 79 Figura 4.25: Gerenciamento de usuários cadastrados no sistema. 80 Figura 4.26: Gerenciamento de etiquetas cadastrados no sistema. 81 Figura 4.27: Administração dos usuários do sistema. 82 Figura 4.28: Administração do sistema. 83 4.28. Este valores são os mesmos utilizados para localizar etiquetas no sistema e tem a finalidade de depurar o funcionamento de tal funcionalidade. • Conexões - Esta opção tem a finalidade de exibir de forma gráfica as conexões entre os leitores fı́sicos, lógicos, especificações de relatórios registrados no middleware e o host para o qual deve ser enviadas as informações dos relatórios. A Figura 4.29 demonstra um exemplo de utilização deste opção. Figura 4.29: Opção Conexões do menu Administrar sistema. • hosts Inscritos - A finalidade desta opção é de apresentar todos os hosts inscritos para recebimento de relatórios de eventos de detecção de etiquetas realizadas pelo middleware de acordo com a especificação do relatório. A Figura 4.29 demostra um exemplo de utilização desta opção. • Especificações de relatórios - Esta opção tem a finalidade de demonstrar todas as especificações de relatórios que estão registradas no middleware. Um exemplo de utilização desta opção é exibida na Figura 4.31. • Leitores Lógicos - Esta opção tem a finalidade adicionar, remover e visualizar os leitores lógicos reconhecidos no middleware, Figura 4.32. Para adicionar um novo leitor lógico é necessário conectá-lo com um dependência fı́sica existente na base de dados. Para remover um leitor fı́sico, basta informar o identificador que o mesmo possui. 84 Figura 4.30: Hosts inscritos para recepção de eventos do middleware. 85 Figura 4.31: Especificações de relatórios de eventos. 86 Figura 4.32: Leitores lógicos. 87 • Leitores Fı́sicos - Esta opção tem a finalidade adicionar, remover e visualizar os leitores fı́sicos reconhecidos no middleware, além de conectar e desconectar os leitores fı́sicos com leitores lógicos, Figura 4.33. Para adicionar um novo leitor fı́sico é necessário informar os dados do leitor fı́sico como por exemplo o identificador, a marca, o modelo e o endereço IP do mesmo. Para remover um leitor fı́sico basta selecioná-lo na lista de leitores fı́sicos existentes. Figura 4.33: Leitores fı́sicos. A opção de conectar um leitor fı́sico a um lógico permite agrupar leitores fı́sicos com o mesmo sentido de negócio em um só leitor lógico. Já a opção de desconectar um leitor fı́sico de um lógico tem a finalidade de desagrupar o leitor fı́sico de um grupo lógico. 4.5.6 Considerações finais Para a correta execução do software na parte cliente, é indicado o explorador de internet Mozilla Firefox na versão 2.0.0, pois na presente data a mais nova versão do mesmo explorador, versão 3.0.0, não dava suporte à execução dos serviços do I-Locate de forma satisfatória. 88 Capı́tulo 5 Conclusão O principal objetivo do trabalho foi desenvolver um software para auxiliar o controle e monitoração de acesso de usuário no HUB utilizando a tecnologia RFID. Para isso foi necessário um estudo aprofundado da RFID bem como os elementos de uma rede RFID proposto pela EPCGlobal. Além disso, foi necessário investigar os processos de negócio existentes, por meio de pesquisas e entrevistas, no HUB para que a especificação dos requisitos funcionais do software pudesse ser definida. O resultado de tais estudos foi a elaboração o sistema I-Locate, que utiliza a tecnologia RFID para localização de pessoas nas dependências fı́sicas do hospital. Sua arquitetura obedece ao padrão de arquitetura especificado pela EPCGlobal, o que lhe garante credibilidade neste ponto de vista. Na visão de atendimento aos requisitos funcionais, o sistema atende plenamente todos os requisitos definidos sendo uma proposta pronta para uso exceto pelo fato da ausência da implementação adaptadores para os leitores fı́sicos, os quais deveriam ser escolhidos pelo próprio HUB no momento da implantação. Caso fosse implantado em situações reais, este sistema refletiria na redução da quantidade de agentes de segurança que necessitem monitorar as dependências fı́sicas, além de assegurar maior organização e confiabilidade dos dados dos registros de acesso, permitindo inclusive auditoria por parte do sistema, uma vez que os registros de acesso não podem ser excluı́dos por nenhum usuário do sistema. 5.1 Trabalhos futuros Abaixo são apresentadas algumas funcionalidades e caracterı́sticas que podem ser adicionadas ao sistema I-Locate conforme a maturação do software. • Auditoria de registro de monitoração de eventos de etiquetas na forma gráfica: Atualmente o sistema oferece este serviço, entretanto ele disponibiliza os resultados em forma de tabela. Uma forma de representação gráfica desta mesma funcionalidade permitia melhor visualização da auditoria por parte dos usuário do sistema. • Interoperabilidade das funcionalidades do sistema I-Locate com o sistema de registro de pacientes existentes no HUB. É de grande valia disponibilizar um serviço SOAP para que os sistemas informatizados no HUB pudessem 89 registrar os pacientes que estão atualmente nas dependências fı́sicas. Com a implementação deste item seria possı́vel consultar a localização do paciente no hospital por meio de outros sistemas. • Implementação de um caso de uso para atualizar a regularidade de do usuário que está em horário irregular, isto é, se o usuário ultrapassar da hora estimada o agente de segurança poderá atualizar a hora prevista para saı́da se julgar necessário. • Implementação de um driver para ser utilizado no adaptador de leitores do middleware: este trabalho limitou-se a utilizar um software para emular o comportamento de um leitor fı́sico verdadeiro. É de grande utilidade implementar o adaptador do driver nativo do leitor para que o sistema se torne realmente funcional. • Implementação de serviços de monitoração de objetos para o HUB: O sistema foi projetado para monitorar somente pessoas que adentrassem nas dependências do hospital. Um serviço de monitoração de objetos seria de grande importância, pois o ambiente hospitalar possui uma grande variedade de objetos pequenos, porém valiosos, visando aumentar a segurança do recinto contra furtos dos objetos citados. • Generalização da estrutura da rede RFID e o sistema de controle e monitoração de acesso propostos neste trabalho para que seja aplicada a qualquer organização que queira utilizar tais serviços. • Criação de procedimentos que evitem a separação fı́sica do portador da etiqueta da mesma quando o portador tiver o registro de acesso aberto, para que não seja possı́vel passar a etiqueta a outro portador mal intencionado. 90 Capı́tulo 6 Anexo 6.1 Detalhamento da especificação dos casos de uso do sistema I-Locate Usuário do sistema Descrição do ator: Qualquer usuário do sistema será representado por este ator, pois os outros atores do sistema estendem os comportamentos deste ator como mostrado na Figura 4.5. Nome do caso de uso Objetivo 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. Fluxo principal 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; 91 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 confirmaçã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. Nome do caso de uso Objetivo Incluir registro de etiqueta Inserir informações de uma nova etiqueta no sistema; Fluxo principal 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; 92 Nome do caso de uso Objetivo Pesquisar registro de etiquetas Pesquisar registros de etiquetas que estão cadastradas no sistema. Fluxo principal 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 Objetivo Atualizar registro de etiqueta 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; 93 Nome do caso de uso Objetivo 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. Fluxo principal 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. 94 Nome do caso de uso Objetivo Incluir interessado Incluir informações de identificação do usuário interessado no sistema. Fluxo principal 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; Nome do caso de uso Objetivo Pesquisar interessados Pesquisar usuário interessados existentes no sistema. Fluxo principal 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; 95 Nome do caso de uso Objetivo Atualizar dados do interessado Atualizar as informações de usuários interessados no sistema. Fluxo principal 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; Nome do caso de uso Objetivo 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. Fluxo principal 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; 96 Nome do caso de uso Objetivo 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; Fluxo principal 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; Nome do caso de uso Objetivo Consultar localização de usuário Consulta a atual localização fı́sica do usuário no HUB. Fluxo principal 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; 97 Nome do caso de uso Objetivo Registrar entrada de interessados 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; 98 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. 99 Nome do caso de uso Objetivo 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. Fluxo principal 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; 100 Nome do caso de uso Objetivo Consultar registro de interessado existente Pesquisar usuários interessados registrados no sistema. Fluxo principal 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. 101 Nome do caso de uso Objetivo Consultar relatório de monitoração Pesquisa os registros de monitoração de etiquetas no HUB. Fluxo principal 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 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 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. Fluxo principal 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; 102 Nome do caso de uso Objetivo 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 Fluxo principal 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 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 Fluxo principal 1. O ator insere o nome do leitor fı́sico; 2. O sistema remove o leitor fı́sico da base de dados; Nome do caso de uso Objetivo 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. Fluxo principal 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; 103 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 Incluir leitor lógico Incluir um leitor lógico no sistema e relaciona-lo com uma dependência fı́sica. Fluxo principal 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; Nome do caso de uso Objetivo 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. Fluxo principal 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; 104 Nome do caso de uso Objetivo 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. Fluxo principal 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 Pesquisar todas as especificações de relatórios de eventos no middleware. Objetivo 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. Fluxo principal 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; 105 Nome do caso de uso Objetivo 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. Fluxo principal 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 Pesquisar nó de conexões do middleware para envio de eventos Objetivo 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. Fluxo principal 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 pesquisa; Nome do caso de uso Objetivo existe as informações da Pesquisar etiquetas monitoradas pelo sistema Pesquisar os últimos eventos gerados pelas presenças das etiquetas nas dependências fı́sicas do HUB. Fluxo principal 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 106 Descrição do ator: Responsável por gerir os usuários e seus respectivos perfis de acesso ao sistema. Nome do caso de uso Objetivo Incluir usuário de sistema Incluir um novo usuário do sistema e definir seu perfil de acesso. Fluxo principal 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; 107 Nome do caso de uso Objetivo Atualizar cadastro de usuário do sistema Atualizar os cadastros dos usuários do sistema existentes. Fluxo principal 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; Nome do caso de uso Objetivo 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. Fluxo principal 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; 108 Referências [Brown and Wiggers, 2005] Brown, D. and Wiggers, E. (2005). Planning for proliferation: The impact of rfid on the network. http://newsroom.cisco.com/dlls/2005/Whitepaper 031105.pdf. [CUHK, 2008a] CUHK (2008a). Cuhk rfid http://mobitec.ie.cuhk.edu.hk/rfid/middleware/index.htm. midldleware. [CUHK, 2008b] CUHK (2008b). Quick start guide of middleware installation. http://mobitec.ie.cuhk.edu.hk/rfid/middleware/doc/Middleware SDD v1.0.pdf. Página 14. [Davi Silva, 2006] Davi Silva, A. V. (2006). Modelagem de processos organizacionais - controle de acesso de pessoas no hospital universitário de brası́lia. Dept. Ciências da Computação - CIC, Universidade de Brası́lia; Brası́lia DF Brasil. [EPCIS, 2008] EPCIS (2008). Accada epcis. http://www.fosstrak.org/. [Finkenzeller, 2003] Finkenzeller, K. (2003). RFID Handbook: Fundamentals and Application in Contactless Smart Cards and Identification, 2. ed. Wiley. [Gazette, 2008] Gazette (2008). Rfid implants for payment systems. http://tecnologia.terra.com.br/interna/0,,OI1079486-EI4805,00.html. [GORDON, 2006] GORDON, S. R. R. G. (2006). Sistemas de informação: Uma Abordagem Gerencial. Editora LTC. [Himanshu Bhatt, 2005] Himanshu Bhatt, B. G. (2005). RFID Sourcebook. Prentice Hall PTR. [Himanshu Bhatt, 2006] Himanshu Bhatt, B. G. (2006). O’Reilly. RFID Essentials. [HUB, 2007] HUB (2007). http://www.hub.br. [Kanda, 2007] Kanda, T. (2007). Analysis os people trajectories with ubiquitous sensors in a science museum. In IEEE International Conference on Robotics and Automation. IEEE. [LAUDON, 2007] LAUDON, K. C. (2007). Sistemas de Informação Gerenciais. Pearson Education. 109 [Maximiano, 1995] Maximiano, A. C. A. (1995). Introdução à Administração. editora Atlas S.A. [NetworkTM, 2006] NetworkTM, E. (2006). Rfid epc essential. http://www.epcglobalinc.org/what/cookbook/chapter1/002– RFID EPC Essentials v1.pdf. [RfiIdJournal, 2007] RfiIdJournal (2007). http://www.rfidjournal.com/article/articleview/1338/1/129/. Rfiidjournal. [SANTINI, 2006] SANTINI, A. G. (2006). Rfid. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) Centro Universitário de Votuporanga. Votuporanga, São Paulo - Brasil. [teleco, 2008] teleco (2008). Rfid: http://www.teleco.com.br/tutoriais/tutorialrfid2/pagina 3.asp. Aplicações. [theregister, 2008a] theregister (2008a). Feds approve human rfid implants. http://www.theregister.co.uk/2004/10/14/human rfid implants/. [theregister, 2008b] theregister (2008b). World cup tickets will contain rfid chips. http://www.theregister.co.uk/2005/04/04/world cup rfid/. [Weiser, 1993] Weiser, M. (1993). Some computer science issues in ubiquitous computing. Commun. ACM, 36(7):1–8. [Weiser and Brown, 1997] Weiser, M. and Brown, J. S. (1997). The coming age of calm technolgy. pages 1–5. [Yi Zhi Zhao, 2007] Yi Zhi Zhao, O. P. G. (2007). Distributed design of rfid network for large-scale rfid deployment. In IEEE International Conference on Industrial Informatics. IEEE. 110